This Is How the AI Bubble Will Pop

Mike's Notes

This greed-driven frenzy over AI has built a massive speculative bubble. It confirms what I have read from Ray Dalio, Jim Miller, John Maudlin, Jack Barnes, Dr Doom, et al.

The bubble is already 4x the size of the one in 2007. When it bursts, the middle-class hysteria will blame all Jews, especially in the US, where the implosion will be the greatest.

I think AI is useful and has a great future after a lot more R&D, but not in the hands of these idiots.

When Ajabbi get financial, it will hold gold.

I discovered this article via Amazing CTO.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Amazing CTO
  • Home > Handbook > 

Last Updated

31/10/2025

This Is How the AI Bubble Will Pop

By: Derek Thompson
Derek Thompson: 02/10/2025

The AI infrastructure boom is the most important economic story in the world. But the numbers just don't add up.

Some people think artificial intelligence will be the most important technology of the 21st century. Others insist that it is an obvious economic bubble. I believe both sides are right. Like the 19th century railroads and the 20th century broadband Internet build-out, AI will rise first, crash second, and eventually change the world.

The numbers just don’t make sense. Tech companies are projected to spend about $400 billion this year on infrastructure to train and operate AI models. By nominal dollar sums, that is more than any group of firms has ever spent to do just about anything. The Apollo program allocated about $300 billion in inflation-adjusted dollars to get America to the moon between the early 1960s and the early 1970s. The AI buildout requires companies to collectively fund a new Apollo program, not every 10 years, but every 10 months.

Exponential View

It’s not clear that firms are prepared to earn back the investment, and yet by their own testimony, they’re just going to keep spending, anyway. Total AI capital expenditures in the U.S. are projected to exceed $500 billion in 2026 and 2027—roughly the annual GDP of Singapore. But the Wall Street Journal has reported that American consumers spend only $12 billion a year on AI services. That’s roughly the GDP of Somalia. If you can grok the economic difference between Singapore and Somalia, you get a sense of the economic chasm between vision and reality in AI-Land. Some reports indicate that AI usage is actually declining at large companies that are still trying to figure out how large language models can save them money.

Every financial bubble has moments where, looking back, one thinks: How did any sentient person miss the signs? Today’s omens abound. Thinking Machines, an AI startup helmed by former Open AI executive Mira Murati, just raised the largest seed round in history: $2 billion in funding at a $10 billion valuation. The company has not released a product and has refused to tell investors what they’re even trying to build. “It was the most absurd pitch meeting,” one investor who met with Murati said. “She was like, ‘So we’re doing an AI company with the best AI people, but we can’t answer any questions.” Meanwhile, a recent analysis of stock market trends found that none of the typical rules for sensible investing can explain what’s going on with stock prices right now. Whereas equity prices have historically followed earnings fundamentals, today’s market is driven overwhelmingly by momentum, as retail investors pile into meme stocks and AI companies because they think everybody else is piling into meme stocks and AI companies.

Every economic bubble also has tell-tale signs of financial over-engineering, like the collateralized debt obligations and subprime mortgage-backed securities that blew up during the mid-2000s housing bubble. Ominously, AI appears to be entering its own phase of financial wizardry. As the Economist has pointed out, the AI hyperscalers—that is, the largest spenders on AI—are using accounting tricks to depress their reported infrastructure spending, which has the effect of inflating their profits1. As the investor and author Paul Kedrosky told me on my podcast Plain English, the big AI firms are also shifting huge amounts of AI spending off their books into SPVs, or special purpose vehicles, that disguise the cost of the AI build-out.

My interview with Kedrosky received the most enthusiastic and complimentary feedback of any show I’ve done in a while. His level of insight-per-minute was off the charts, touching on:

  • How AI capital expenditures break down
  • Why the AI build-out is different from past infrastructure projects, like the railroad and dot-com build-outs
  • How AI spending is creating a black hole of capital that’s sucking resources away from other parts of the economy
  • How ordinary investors might be able to sense the popping of the bubble just before it happens
  • Why the entire financial system is balancing on big chip-makers like Nvidia
  • If the bubble pops, what surprising industries will face a reckoning

Below is a polished transcript of our conversation, organized by topic area and adorned with charts and graphs to visualize his points. I hope you learn as much from his commentary as much as I did. From a sheer economic perspective, I don’t think there’s a more important story in the world.

AI SPENDING: 101

Derek Thompson: How big is the AI infrastructure build-out?

Paul Kedrosky: There’s a huge amount of money being deployed and it’s going to a very narrow set of recipients and some really small geographies, like Northern Virginia. So it’s an incredibly concentrated pool of capital that’s also large enough to affect GDP. I did the math and found out that in the first half of this year, the data-center related spending—these giant buildings full of GPUs [graphical processing units] and racks and servers that are used by the large AI firms to generate responses and train models—probably accounted for half of GDP growth in the first half of the year. Which is absolutely bananas. This spending is huge.


JP Morgan chart showing the rising contribution to GDP growth from tech capex

Thompson: Where is all this money going?

Kedrosky: For the biggest companies—Meta and Google and Amazon—a little more than half the cost of a data center is the GPU chips that are going in. About 60 percent. The rest is a combination of cooling and energy. And then a relatively small component is the actual construction of the data center: the frame of the building, the concrete pad, the real estate.

HOW AI IS ALREADY WARPING THE 2025 ECONOMY

Thompson: How do you see AI spending already warping the 2025 economy?

Kedrosky: Looking back, the analogy I draw is this: massive capital spending in one narrow slice of the economy during the 1990s caused a diversion of capital away from manufacturing in the United States. This starved small manufacturers of capital and made it difficult for them to raise money cheaply. Their cost of capital increased, meaning their margins had to be higher. During that time, China had entered the World Trade Organization and tariffs were dropping. We’ve made it very difficult for domestic manufacturers to compete against China, in large part because of the rising cost of capital. It all got sucked into this “death star” of telecom.

So in a weird way, we can trace some of the loss of manufacturing jobs in the 1990s to what happened in telecom because it was the great sucking sound that sucked all the capital out of everywhere else in the economy.

The exact same thing is happening now. If I’m a large private equity firm, there is no reward for spending money anywhere else but in data centers. So it’s the same phenomenon. If I’m a small manufacturer and I’m hoping to benefit from the on-shoring of manufacturing as a result of tariffs, I go out trying to raise money with that as my thesis. The hurdle rate just got a lot higher, meaning that I have to generate much higher returns because they’re comparing me to this other part of the economy that will accept giant amounts of money. And it looks like the returns are going to be tremendous because look at what’s happening in AI and the massive uptake of OpenAI. So I end up inadvertently starving a huge slice of the economy yet again, much like what we did in the 1990s.

Thompson: That’s so interesting. The story I’m used to telling about manufacturing is that China took our jobs. “The China shock,” as economists like David Autor call it, essentially took manufacturing to China and production in Shenzhen replaced production in Ohio, and that’s what hollowed out the Rust Belt. You’re adding that telecom absorbed the capital.

And now you fast-forward to the 2020s. Trump is trying to reverse the China shock with the tariffs. But we’re recreating the capital shock with AI as the new telecom, the new death star that’s taking capital that might at the margin go to manufacturing.

Kedrosky: It’s even more insidious than that. Let’s say you’re Derek’s Giant Private Equity Firm and you control $500 billion. You do not want to allocate that money one $5 million check at a time to a bunch of manufacturers. All I see is a nightmare of having to keep track of all of these little companies doing who knows what.

What I’d like to do is to write 30 separate $50 billion checks. I’d like to write a small number of huge checks. And this is a dynamic in private equity that people don’t understand. Capital can be allocated in lots of different ways, but the partners at these firms do not want to write a bunch of small checks to a bunch of small manufacturers, even if the hurdle rate is competitive. I’m a human, I don’t want to sit on 40 boards. And so you have this other perverse dynamic that even if everything else is equal, it’s not equal. So we’ve put manufacturers who might otherwise benefit from the onshoring phenomenon at an even worse position in part because of the internal dynamics of capital.

Thompson: What about the energy piece of this? Electricity prices rising. Data centers are incredibly energy thirsty. I think consumers will revolt against the construction of local data centers, but the data centers have enormous political power of their own. How is this going to play out?

Kedrosky: So I think you’re going to rapidly see an offshoring of data centers. That will be the response. It’ll increasingly be that it’s happening in India, it’s happening in the Middle East, where massive allocations are being made to new data centers. It’s happening all over the world. The focus will be to move offshore for exactly this reason. Bloomberg had a great story the other day about an exurb in Northern Virginia that’s essentially surrounded now by data centers. This was previously a rural area and everything around them, all the farms sold out, and people in this area were like, wait a minute, who do I sue? I never signed up for this. This is the beginnings of the NIMBY phenomenon because it’s become visceral and emotional for people. It’s not just about prices. It’s also about: If you’ve got a six acre building beside you that’s making noise all the time, that is not what you signed up for.

A very specific prediction for how and why AI bubble will pop

> The rest of the article is for Derek Thompson paying subscribers. <

Workspace Menu

Mike's Notes

Working draft for the outline of the workspace menu. Testing now, all subject to change.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

2/11/2025

Workspace Menu

By: Mike Peters
On a Sandy Beach: 30/10/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Every Workspace comes with several types of menus (explained here for left-to-right writing systems)

  • Every workspace has 3 Standard 1 menus to the left.
  • Each workspace has some unique Workspace-specific menus.
  • Some workspaces have one or more Context menus.
  • Every workspace has 3 Standard 2 menus to the right.

Menu types

  • Standard 1
    • Home
    • File
    • Edit
  • Workspace-specific
    • Arrange
    • Bookmarks
    • Design
    • Layout
    • Presentation
    • Network
    • Translate
    • etc
  • Context
    • Data Model 
    • Import Data
    • Schema
    • Freight Consignment
    • etc
  • Standard 2
    • View
    • Window
    • Help

Menu hierarchy example

  • Home (Standard 1)
    • Dashboard
    • Preferences
    • Workspaces

  • File (Standard 1)
    • New
    • Open
    • ---------------
    • Close
    • Save
    • Save As
    • Revert
    • Delete
    • ---------------
    • Page setup
    • Print
    • ---------------
    • Info
      • Versions
    • Import
    • Export
    • ---------------
    • Exit
  • Edit (Standard 1)
    • Cut
    • Copy
    • Paste
    • Clear
    • Select All
    • ---------------
    • Show Clipboard
  • --------------------------------------------------------
  • Design (Workspace-specific)
    • Font
      • Font Type
      • Font Size
    • Paragraph
    • Style
    • Editing
  • Bookmarks (Workspace-specific)

  • Arrange (Workspace-specific)
    •  
  • --------------------------------------------------------
  • Context 1 (Context)

  • Context 2 (Context)

  • Context 3 (Context)

  • --------------------------------------------------------
  • View (Standard 2)
    • Show
    • Zoom
  • Window (Standard 2)
    • Dashboard
      • Arrange
    • Workspace
    • Settings
      • Language
      • Acessibility
      • Time Zone
    • Updates
  • Help (Standard 2)
    • Help
    • Feedback
      • Roadmap
      • Vote
      • Feature Request
    • Support
      • Forum
      • Chat
      • Office Hours
      • Contact
    • Training
      • Docs
      • How-to-guide
      • Tutorials
      • Reference
    • About Pipi

Menu Config Database

Already built and tested. Stores all tab and tool definitions.

Layout options

The workspace menu UI will come in several layout options, mirroring popular platforms. People will be able to choose whatever they prefer in settings. DevOps account developers will be able to create more options for users to choose from. A quick survey of layout looks includes;

  • "Ribbon"
  • "Like Google Workspace"
  • Pipi 4
  • "Like Adobe"
  • "Like Service Now"
  • "Like Zoho"
  • "Like Odoo"
  • "Like Netsuite"
  • etc
I personally prefer minimalist.

Acessibility

There will be menu UI options for screen readers, braille, and other accessibility features.

Ribbon layout

I'm working on the static ribbon version of the workspace menu. The CSS and working versions will use MetroUI CSS and HTMX.

The workspace "ribbon-like" menu and tabs roughly follow common conventions used by other software, so people don't get lost. With 3 context tabs reserved for any situation. The first draft will be used for running experiments.

What's next

Replace all 3,800 HTML Workspace files with the changes.

Lots of trial-and-error experimenting is next. You can watch by visiting the workspace mockup.

The design system docs will need to be updated.

Asked to do something illegal at work? Here’s what these software engineers did

Mike's Notes

No excuse ever for being a crook. Amazing CTO had a link to this article on Pragmatic Engineer.

Resources

References

  • The Software Engineer's Guidebook, by Gergely Orosz.

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Amazing CTO
  • Home > Ajabbi Research > Library > Subscriptions > Pragmatic Engineer
  • Home > Handbook > 

Last Updated

29/10/2025

Asked to do something illegal at work? Here’s what these software engineers did

By: Gergely Orosz
Pragmatic Engineer: 02/10/2025

Writing The Pragmatic Engineer. Previously at Uber, Skype, Microsoft. Author of The Software Engineer's Guidebook..

Update on 2 Oct 2025: back in 2021, Charlie Javice, CEO of student loan startup Frank pressured a software engineer to inflate customer numbers. She told the engineer that she did not believe that anyone would end up in an ‘orange jumpsuit’ just for this. Still, the engineer refused – and was proven right. Javice, in fact, did end up in an orange jumpsuit, sentenced to 7 years of prison in 2025 for fraud.

The below topic was sent out to full subscribers of The Pragmatic Engineer, three weeks ago, in The Pulse #66. I have received several messages from people asking if they can pay to “unlock” this information for others, given how vital it is for software engineers. It is vital, and so I’m sharing this with all readers, without a paywall. In the unlikely case that you are asked to do something fishy or illegal: I hope the below will help decide how to do the right thing.

What would you do if you learned your company is up to something illegal like stealing customer funds, or you’re asked to make code changes that will enable something illegal to happen, like misleading investors, or defrauding customers? Here are three real-life cases, where what engineers and engineering managers did had serious consequences.

FTX: an engineering director went along with the fraud

A trial related to FTX, the cryptocurrency exchange which allegedly defrauded investors of $9B, is ongoing. Day 9 of the trial of former FTX CEO Sam Bankman-Fried trial, heard testimony from Nishad Singh, who joined the business as a software engineer, and later became an engineering director. Here is software engineer and writer Molly White summarizes of his evidence:

“To hear Singh tell it, he didn’t even really realize what was going on at FTX and Alameda Research until September 2022 — only a month or two before everything came crashing down. (...) Several times throughout various testimonies, we’ve seen a document written by Sam Bankman-Fried, in which he describes his thinking that Alameda Research should be shut down. That document was, ultimately, how Singh learned in September 2022 that Alameda Research had taken billions of dollars of customer funds from FTX. 

This was when Gary Wang told Singh that Alameda was borrowing massive amounts of customer money from FTX — at the time, around $13 billion of it. Singh testified that he felt ‘really afraid’, and called an in-person meeting immediately. Bankman-Fried, who was sitting next to Singh at the time, ‘seemed unsurprised and made up what I understood to be a false excuse for dodging the meeting.’ Singh, Ellison, and Wang met without him, and Singh confirmed his fears: that he had not misunderstood Wang, and that Alameda had actually taken customer funds to that extent.”

Okay, so in September 2022, Singh had confirmation that something illegal was happening at the company, which he had no direct knowledge of, until then. At that point, if he wanted to avoid being an accomplice to potentially illegal activity, his options were:

  • Talk to a lawyer on how to avoid assisting a crime
  • Turn whistleblower. See the tech whistleblower guide
  • Quit the company, ensuring he did not further aid this activity 

The smart thing would have been to do #1. The profitable thing could have been to do #2 because in the US, a whistleblower may receive a whistleblower reward of between 10-30% of what the government recovers from fraudulent activities. The final choice #3 is hard, but could have meant Singh would not have had to plead guilty as he did. 

Here’s what Singh did instead: he asked for a personal meeting with Bankman-Fried and confronted him about the missing funds. However, Bankman-Fried replied there not much to worry about, and that they’d repay the funds by raising more money from investors (!!) This should have been the point at which Singh quit. Instead:

“He thought about leaving the company then, he testified, but worried that his departure could cause everything to fall apart. He felt that if he stayed, maybe he could help the companies make back what they owed.”

For the next two months, Singh tried to make things better, but it was fruitless. FTX collapsed in November 2022.

Lesson #1: when you discover fraud may be happening, do not “stay around to fix it.” Any other approach would have been better for Singh; seeking legal advice, turning whistleblower, or quitting on the spot.

To be fair, Singh didn’t seen totally clueless, and it seems he decided to profit on the developments. Days after he found about this fraud, he took a $3.7M loan from FTX (!!) to buy a house, The Verge pointed out. It’s exactly the type of thing you don’t want to do after you discover fraud.

Now, Singh is facing up to 75 years in jail thanks to his decision to aid the company after discovering the fraud. His sentence will most likely be reduced due to his plea deal, but any course of action which leads to a criminal conviction is surely a grave error of judgment.

Update in Oct 2025: in the end, Nishad Singh was spared from prison, and received 3 years of supervised release. The judge was persuaded that Singh’s involvement with the fraud was far more limited than that of FTX founder Sam Bankman-Fried or Caroline Ellison, the former CEO of sister hedge fund Alameda Research.

Frank: a software engineer refuses to fake customer data

Frank was a student loan startup founded by Charlie Javice in 2016. In 2019, Javice was featured on the Forbes “30 under 30” finance list, suggesting she was a high-flying founder:


How Charlie Javice appeared on the Forbes 30 under 30 list in 2019. We now know the 300,000 user number was fake. Source: Forbes

It certainly seemed like Charlie Javice was a standout founder; in 2021, JP Morgan purchased Frank for $175M. However, things turned sour quickly. JP Morgan thought it bought a startup with 5 million customers, which worked with 6,000 schools. But after the purchase, this data was found to be mostly fake.

Let’s get to a software engineer’s involvement. This April, founder Charlie Javice was arrested, and a lawsuit is ongoing between her, former Chief Growth Officer Olivier Amar, and JP Morgan. From to this lawsuit, we get an inside look at how events unfolded inside Frank.

In 2021, an engineer was asked to produce fake data for 4.2M non-existent customers. As acquisition talks were ongoing, JP Morgan wanted to validate that Frank had the nearly 5M customers it claimed. In reality, Frank had 293,000 customers, so the CEO asked an engineer to fake the data and turn this list into 4.2M members. Here’s what happened next – from the lawsuit:

“[In 2021] Javice [CEO], Amar [Chief Growth Officer] and the Director of Engineering then had a Zoom meeting during which Javice and Amar asked the Director of Engineering to help them create a synthetic list of customer data. She asked the Director of Engineering if he could help take a known set of FAFSA application data and use it to artificially augment a much larger set of anonymous data tht her systems had collected over time.

The Director of Engineering questioned whether creating and using such a data set was legal, but Javice tried to assure the engineer by claiming that this was perfectly acceptable in an investment situation and she did not believe that anyone would end up in an ‘orange jumpsuit’ over this project.”

Lesson #2: when your manager claims they don’t believe anyone would end up in an “orange jumpsuit,” assume that someone definitely could. The engineering director’s next step? They refused:

“The Director of Engineering was not persuaded and told Javice and Amar that he would not perform the task, and only would send them the file containing Frank’s actual users, which amounted to approximately 293,000 individuals at the time.”

And this engineering director played it right, as the people who are likely to go to jail and end up in orange jumpsuits are the other two people on the call, who knowingly went along with the illegal.

Pollen: an engineer told to double charge customers by the CEO

Last year, I published my first – and to date only– investigative article on how events tech startup Pollen raised $200M and then collapsed, owing months of wages to staff. In the investigation, I focused on an unusual detail: $3.2M worth of funds taken months early from customers. The incident was described internally by Pollen as a mistake, and an incident review should have followed. Even more confusing, the company blamed the payments processor Stripe for the incident.

The reality was that this was a very deliberate double charge. I could not share this fact at the time – as the company threatened me with libel after I informed them of this detail – but the BBC has now produced a documentary revealing details about this deliberate double charge that was covered up as an outage. From the documentary:

[Narrator] “Pollen initially told some customers that the problem was with their payments provider. Later, Callum [the CEO] addressed his staff who were demanding to know what happened.”

[CEO of Pollen talking] “All that happened was that a couple millions of dollars of payment plans that were due to be paid at a later month were then paid earlier. It’s being investigated. We’ve committed already that once that investigation is done, it will be shared with the company so that people understand what happened.”

[Narrator] “With over 1,500 customers impacted, rumors began to circulate about the causes of the incident.”

[Dan Taylor, managing editor at Tech.eu] “From my understanding, there was a creative code ‘malfunction’ that all of the sudden, double charged customers. But that double charge magically happened to meet Pollen’s payroll, that month. Hmm! Odd, don’t you think?”

[Narrator] “The internal investigation due to be shared with the company was never completed, but a group of Pollen staff did their own, unofficial digging. (...) The code contained in the report confirms that the customer's monthly payment plans had been manually altered, which meant that double or triple charges will take place on a single day, without the customer’s authorization.”

The engineer making this change even did a test run the day before, to ensure that this code change “correctly” double charges customers! A former Pollen software engineer appearing in the documentary also makes the point that any code changing production code in payments needs to go through code review, so whoever made this change could have not been acting alone.

Two days after the incident, a senior engineering team member sent an internal chat message to 3 colleagues, where they admit that they had run the script at the request of the CEO. Here is what this message said:

“Also want to come clean that it was me who ran a bad script - in hindsight I wasn’t knowledgeable enough to alter a subset of payment plans for Balvin [one of the events organized by Pollen]. I did this as a special request from Callum and didn’t want to raise on call to handle. It’s been a long week and I displayed a very poor form of judgement.”

In the video, a Pollen software engineer is shown the message, and he says: “I’m not sure I buy this. It seems a bit fishy.”

Lesson #3: if the CEO asks you to do something potentially illegal – document it, and consider not doing it. We don’t know what happened with the senior engineering member who carried out the code changes, following a request from the CEO. This person could have said no, like the engineering director at Frank did. The message sent a few days ago already said that this person regretted doing so, and it’s unlikely that this action was worth the risk it carried.

Update in Oct 2025: no criminal charges that I am aware of have been made related to this double charging at Pollen.

If you take one lesson from this, it’s that you can always say no. In these three stories, the only engineer who’s legally safe is the former engineering director at Frank who point blank refused to assist what could be an illegal request. The engineering director at FTX who stayed after he confirmed fraud was occurring is now facing jail time, while the senior engineering member at Pollen is at the mercy of the UK police, and how they deal with what could be a potential wire fraud case. 

Subscribe to my weekly newsletter to get articles like this in your inbox. It's a pretty good read - and the #1 tech newsletter on Substack.

The Pragmatic Engineer Podcast

Deepdives with experienced engineers and tech professionals who share their hard-earned lessons, interesting stories and advice they have on building software.

Listen to it on Spotify, on Apple, on YouTube, or on the web.

The Software Engineer's Guidebook

I wrote The Software Engineer's Guidebook. Here is what Tanya Reilly, senior principal engineer and author of The Staff Engineer's Path says about it:

"From performance reviews to P95 latency, from team dynamics to testing, Gergely demystifies all aspects of a software career. This book is well named: it really does feel like the missing guidebook for the whole industry."

The Software Engineer's Guidebook

Get the book here.

Annual conference talk

I do one conference talk every year. My last one was at LDX3 (formerly: LeadDev) in London, on 16 June 2025. You can now watch the full talk, online:

Software engineering with LLMs in 2025: reality check

LDX3 is running conferences in New York and in Berlin in the fall of 2025. If you're an engineering leader, check them out.

What We Know About the NPM Supply Chain Attack

Mike's Notes

Lesson: don't rely on anything. This article was recommended in Amazing CTO. Thanks, Stephan.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Amazing CTO
  • Home > Handbook > 

Last Updated

28/10/2025

What We Know About the NPM Supply Chain Attack

By: Jeffrey Francis Bonaobra, Joshua Aquino
Trend Micro: 18/09/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Key takeaways

  • Attackers reportedly launched a targeted phishing campaign to compromise Node Package Manager (NPM) maintainer accounts and inject malicious code into widely used JavaScript packages.
  • Certain malicious packages covertly diverted cryptocurrency assets by hijacking web APIs and manipulating network traffic.
  • One of the attack’s payloads is the Shai-hulud worm, which is delivered through compromised packages, steals cloud service tokens, deploys secret-scanning tools, and spreads to additional accounts.
  • Based on Trend Micro’s telemetry, organizations across North America and Europe have been among the most affected by one of the payloads, Cryptohijacker. There have been no detections of the Shai-Hulud worm so far.
  • Trend Vision One™ detects and blocks the indicators of compromise (IOCs) outlined in this blog, and provides customers with tailored threat hunting queries, threat insights, and intelligence reports.
  • On September 15, the Node Package Manager (NPM) repository experienced an ongoing supply chain attack, in which the attackers executed a highly targeted phishing campaign to compromise the account of an NPM package maintainer. With privileged access, the attackers injected malicious code into widely used JavaScript packages, threatening the entire software ecosystem. Notably, the attack has disrupted several key NPM packages, including those integral to application development and cryptography.

According to StepSecurity, the malicious actors behind this incident used similar techniques with the Nx supply chain attack last month. As of September 16, researchers at Socket have already identified close to 500 impacted NPM packages.

In this blog entry, Trend™ Research details an overview of the recent NPM ecosystem compromises, what SOC teams need to know, and security recommendations to avoid this threat.

What types of packages are at risk

The malicious modifications were made to critical JavaScript libraries, including those supporting development frameworks and cryptographic functions. Packages impacted by this attack are those with extremely high global download rates – over 2.6 billion per week – affecting a vast ecosystem of web applications and dependent projects.

Attackers stole cryptocurrency assets

The attackers hijacked web APIs and manipulated network traffic as a means of covertly diverting funds from legitimate channels to wallets they controlled, targeting both organizations and end-users interacting with compromised packages.

Shai-hulud attack chain analysis

One of the payloads is a self-replicating worm, dubbed Shai-hulud after the sandworm in Dune, that was detected in the NPM registry.  Trend Research provides analysis of Shai Hulud, its operational mechanics, and its implications for organizations relying on NPM.

Shai-Hulud stands out for its autonomous replication capability. Instead of a mere infection, Shai-Hulud introduces worm-like propagation, continuously seeking out and compromising additional packages and environments.

Attack chain

The Shai-Hulud attack chain began with a phishing email disguised as an NPM security alert, tricking a developer into revealing credentials (Figure 1). Attackers compromised the developer’s NPM account and uploaded a malicious package. When installed, this package executed JavaScript and embedded Unix shell scripts to establish persistence and start stealing information.

Using stolen GitHub access tokens, the malware authenticated to the GitHub API, checked user permissions, and listed all repositories the victim could access – including private ones. It cloned private repositories to attacker accounts, created a new branch in each, and deployed a malicious workflow to automate data theft.

Next, the malware downloaded and installed TruffleHog to scan for and harvest more secrets from files. It made all stolen repositories public and mirrored their entire history. Sensitive data was then exfiltrated to the attacker using automated web requests.

This chain shows how a single compromised account can lead to the spread of malicious code, credential theft, and mass data leakage across an organization’s entire development environment.

Figure 1. Observed attack chain and deployment of Shai-Hulud from compromised NPM package

The widespread exposure of this threat means that hundreds of packages could have been compromised before initial detection, undermining organizations’ trust in adopting open-source dependencies. The scalability of the attack, enabled by automation, significantly increases both technical and business risks, requiring minimal effort from the attacker once deployed. 

What makes Shai-Hulud distinctive?

Traditional software supply chain threats typically involve single-use payloads or targeted credential theft. Shai-Hulud distinguishes itself through its ability to self-replicate within the NPM ecosystem, using available functionality in post-install scripts to establish secondary and tertiary infections. Once a compromised package is installed, the worm automatically attempts to spread to new targets, creating a multiplying threat that does not rely on human actor intervention after initial deployment.

Key traits:

  • Self-propagation - Shai-Hulud behaves as a worm, automatically infecting additional NPM packages and projects by leveraging existing trust relationships in the open-source community.
  • Autonomy -  The malware runs without direct ongoing operator input, making it more persistent and difficult to contain.
  • Environmental impact - By embedding itself deeply within development and CI/CD environments, Shai-Hulud gains potential access to further credentials, tokens, and sensitive build secrets.

Technical methodology

  • Post-install abuse - The core propagation mechanism centers around malicious post-install scripts. When an infected package is deployed, arbitrary code executes, which may download further payloads or inject malicious scripts into other projects and dependencies.
  • Network activity - The worm can communicate with remote servers to exfiltrate data or receive updates, thus evolving even after initial deployment.
  • Recursive threat vector - Shai-Hulud is engineered for persistence—not just compromising a project once, but remaining a latent risk as dependencies update.

Risk to NPM and open source

The core strength and risk of NPM lies in its vast network of community-driven packages. Shai- Hulud's self-replicating worm design specifically targets this community trust, highlighting how quickly a single malicious actor can impact a disproportionately large segment of developers and software projects.

Shai-Hulud analyis

Malicious workflow injection analysis

The Shai-Hulud worm utilizes an advanced technique by injecting malicious GitHub Actions workflows into targeted repositories, enabling automated propagation and secret exfiltration across an organization’s development environment.

Upon execution, Shai-Hulud prepares the following:

  • Assigns a branch name such as shai-hulud to maintain consistency and help track infections across repositories.
  • Targets .github/workflows/shai-hulud-workflow.yml for the placement of its malicious workflow file.
  • Generates or fetches a YAML workflow file containing the malicious automation payload.

The primary function of the injected workflow, as shown in Figure 2, is to systematically collect and exfiltrate repository secrets:

  • The workflow enumerates all secrets exposed during its CI/CD runtime environment.
  • It packages these secrets into a payload formatted for transmission.
  • Secrets are sent via HTTP(S) requests to attacker-controlled webhook endpoints.

Figure 2. Secret exfiltration mechanism

Shai-Hulud also leverages GitHub’s REST API to automate its lateral movement and establish persistence (Figure 3). The worm checks the validity and permissions of available GitHub authentication tokens to confirm the ability to interact with the API.

Figure 3. GitHub API exploitation

By issuing API requests such as

/user/repos?affiliation=owner,collaborator,organization_member&since=2025-01-01T00:00:00Z&per_page=100

the worm identifies repositories where the compromised account has adequate privileges, filtering by owner, collaborator, or organization member roles and focusing on recent activity (Figure 4).

Figure 4. Github repository discovery

For each eligible repository, the Shai-Hulud worm carries out:

  • Branch creation. It creates a uniquely named branch (e.g., shai-hulud) in the repository to house the injected workflow and isolate malicious changes (Figure 5).

Figure 5. Automated branch creation

  • Workflow file upload. The worm uploads the malicious YAML file to the new branch, setting up ongoing automated secret exfiltration whenever workflows are triggered (Figure 6).

Figure 6. Automated workflow file upload

GitHub repository cloning analysis

Shai-Hulud’s attack chain features an automated process for cloning, migrating, and exposing private GitHub repositories from an organization to an attacker’s infrastructure. The following section outlines the programmatic stages of this cloning activity.

The main orchestration logic coordinates the full cloning cycle – from initialization through repository creation and exposure (Figure 7).

Figure 7. Main function logic for repository cloning

The worm iterates through all identified private repositories within a target organization, utilizing internal logic to ensure each repository is analyzed and handled (Figure 8).

Figure 8. Processing discovered private repositories

Initial checks confirm the presence and validity of required inputs – such as organization name, target username, and GitHub authentication token – to ensure both API compliance and workflow reliability (Figure 9).

Figure 9. Input validation and variable initialization

API interactions are abstracted behind a standardized communication wrapper, responsible for managing authentication (via bearer tokens or OAuth apps) and handling HTTP GET, POST, PUT, and PATCH methods for robust error handling (Figure 10).

Figure 10. Standard API communication wrapper

The process targets only private or internal repositories to maximize stealth and impact. API pagination is implemented to enumerate all repositories within large organizations efficiently (Figure 11).

Figure 11. Repository discovery

For every discovered repository, the worm creates a corresponding destination repository in the attacker’s account – embedding an identifier in the repository description such as “Shai-Hulud Migration” for tracking (Figure 12).

Figure 12. Repository creation under attacker control

Once created, what was a private repository in the victim’s organization is made public under the attacker’s control, facilitating mass data exposure and fingerprinting (Figure 13).

Figure 13. Converting stolen repository to public

To maximize the value of the theft, the worm performs a full mirror clone, capturing not just code contents but also the entire commit and branch history for later exploitation or secondary attacks (Figure 14).

Figure 14. Complete mirror cloning

Through these automated mechanisms, Shai-Hulud rapidly exfiltrates high-sensitivity intellectual property and source code from private repositories, weaponizing it for further data exposure, ransom, or downstream supply chain threats.

Credential harvesting via TruffleHog

As part of its post-compromise activities, Shai-Hulud leverages TruffleHog to further automate credential and secret discovery on compromised environments. The workflow begins by obtaining the latest release of the TruffleHog binary, programmatically retrieving the most recent version available for download (Figure 15).

Figure 15. Retrieving the latest TruffleHog release

Once the appropriate TruffleHog file is identified, the worm downloads the binary, automatically detecting and extracting the correct version based on the operating system present on the victim’s machine (Figure 16).

Figure 16. Downloading and extracting the TruffleHog binary

After extraction, TruffleHog is installed or placed into the environment, making it readily available for use by the malicious workflow (Figures 17 and 18).

Figure 17. TruffleHog installation and environment preparation along with automated secrets scanning and cleanup

Figure 18. TruffleHog installation and environment preparation along with automated secrets scanning and cleanup

The malware then spawns a child process, invoking TruffleHog to scan the local filesystem or target repository contents for high-entropy strings, keys, and other sensitive secrets. This process is conducted in-memory or within a runtime context to evade persistent detection. Once scanning is complete, the TruffleHog binary is deleted to cover tracks and minimize forensic artifacts.

By integrating TruffleHog in this automated fashion, Shai-Hulud markedly increases the volume and quality of exfiltrated secrets, while maintaining operational stealth throughout its attack lifecycle.

Who has been affected so far

Based on Trend's telemetry, attacks involving the Cryptohijacker payload have been reported across various countries, but primarily in North America and Europe. Organizations and developers that depend on widely adopted JavaScript libraries are among those most impacted. However, there have been no detections of the Shai-Hulud worm so far.

Security recommendations

To safeguard their development workflows and sensitive assets from the risks stemming from the ongoing NPM supply chain attack, organizations should prioritize a proactive security stance through the following best practices: 

  • Audit dependencies, focusing on recently updated packages. Review all dependencies, especially those recently modified, and remove or roll back any that appear compromised.
  • Revoke and rotate credentials, especially for NPM accounts. Immediately revoke and replace any credentials or API keys that may have been exposed, prioritizing sensitive accounts.
  • Monitor for evidence of Trufflehog and similar scanning tools in use. Check logs for any anomalous repository scanning activity and proactively scan your own codebase for exposed secrets.
  • Stay updated with advisories from the official NPM registry and trusted sources. Regularly monitor official advisories to apply the latest fixes and recommended actions promptly.
  • Tighten access and security policies. For example, apply the principle of least privilege for all accounts impacting repositories and automation. In addition, enforce multi-factor authentication (MFA) on all developer and CI/CD access points.

Workspace MVP

Mike's Notes

A progress report. It's going rather well.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

27/10/2025

Workspace MVP

By: Mike Peters
On a Sandy Beach: 27/10/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

The workspace UI experimentation and learning have been rapid. As a result, each workspace mockup is replaced with a new, improved version most days.

Static mockup

The HTML table-based mockup is static, incomplete, lacks CSS, and contains made-up information (an MVP). But it has been good enough to learn very fast. This version uses iFrames and is in English.

Additional versions will address accessibility and device/screen size requirements.

URL naming pattern

Previous On a Sandy Beach posts discussed and then described the URL naming pattern. That has worked out.

That has meant naming files and directories using rules.

That is working, with more to figure out.

Deep nesting

The Workspaces contain modules that can be reused, renamed and deeply nested. This needs to happen automatically without causing name collisions. So repeatable and unique URLs. So far, I have gone 3 module levels deep.

Will try a 7-8-level-deep experiment to make sure it's safe.

Groundhog day

3,700 web pages are uploaded every day, replacing the previous 3,700 HTML pages as errors are corrected and features are added.

Names

The names and descriptions of workspaces and modules have been reworked and made consistent across the documentation and workspaces.

URL consistency

Pattern-driven URL links must always work across workspaces, modules, settings, help, menus, how-to-guides, tutorials, and reference.

More work is needed to name and structure tutorials and reference information at Ajabbi Learn. URL link stability will take time to establish.

What's next

More of the above till all the problems disappear and it becomes 100% reliable. 

Then build a demo workspace for a fictitious organisation. eg "West Klingon Hospital", "Valhalla Rail Corp", "Red Baron Airport", "Gotham City Water, "Minas Tirith Power". And users like "Dr Who", "Kermit", "Jabba the Hutt", "Galadrial", etc.

Lots of testing and feedback while having some fun.

Then make the workspaces "live" and usable for those with accounts.

Thinking Like a Data Engineer

Mike's Notes

Great read here. It takes humility to write this. Thanks, Ananth.

Data Engineering Weekly is an excellent newsletter to subscribe to.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Data Engineering Weekly
  • Home > Handbook > 

Last Updated

30/10/2025

Thinking Like a Data Engineer

By: Ananth Packkildurai
Data Engineering Weekly: 23/10/2025

Ananth Packkildurai is a data engineering leader, writer, and author of Data Engineering Weekly, sharing insights on modern data platforms, large-scale pipelines, and AI-driven architectures.

I thought becoming a data engineer meant mastering tools. Instead, it meant learning how to see. I thought the hardest part would be learning the tools — Hadoop, Spark, SQL optimization, and distributed processing. Over time, I realized the real challenge wasn’t technical. It was learning how to think.

Learning to think like a data engineer — to see patterns in chaos, to connect systems to human behavior, to balance simplicity and scale — is a slow process of unlearning, observing, and reimagining. I didn’t get there through courses or certifications. I got there through people.

Four mentors, in four different moments of my life, unknowingly gave me lessons that shaped how I approach engineering, leadership, and even life. Each taught me something not about data, but about thinking systems.

What follows isn’t a tutorial. It’s a map of how four people — and their lessons — rewired how I think.

#1. “Chasing Knowledge.”

One of my friends recently asked why you are constantly reading and writing. It all started with an internship. A family friend of mine helped me find an internship. He was the person who taught me Java — patiently explaining not just syntax, but how to think through logic, abstraction, and design.

When I called him after getting my first full-time job, I expected congratulations or career advice. Instead, he said something that I only understood years later:

Don’t chase money. Chase knowledge. Money will follow.”

The advice struck a chord with me forever. In technology, everything changes — languages, frameworks, stacks, even paradigms. But curiosity compounds. The more you learn, the faster you learn. The more you focus on mastering fundamentals, the easier it becomes to adapt when the next wave arrives.

That advice became a quiet compass throughout my career. Every time I faced a decision — whether to take a higher-paying role or a role that stretched my skills — I thought back to his words. And every single time I chose learning, the money eventually caught up.

It taught me that data engineering is not a sprint to expertise, but a lifelong apprenticeship in curiosity.

#2. “Modeling the World.”

It was in my early days of career as a data engineer that I met another mentor — an industry veteran, family friend, and one of the most grounded data people I’ve ever known.

One day, I asked him a question I thought was simple:

“How do I become a data engineer?”

He didn’t answer directly. He just said, “Go to Walmart and tell me what you see.”

I didn’t get it. But I went.

I walked through aisles, looked at shelves, and bought a few things — shampoo, snacks, and batteries. I came back and said, “Okay, I went. I bought x, y, z. Now what?”

He smiled and said, “Now tell me — how would Walmart model this data?”

That’s when I stopped seeing stores — and started seeing systems. I started describing the data model — a shelves table, a products table, a users table, and an events table. I started seeing not a store, but a database. Every product placement was a joint. Every checkout was an event stream.

That exercise reshaped how I saw the world. Data engineering wasn’t about ETL jobs or pipelines. It was about modeling reality.

When you can take something as ordinary as a store and translate it into entities, relationships, and flows, you start to think like a data engineer.

That mental model helped me immensely later. During one of my interviews at Slack, I was asked to design a data warehouse for Netflix. I didn’t start from schemas or metrics. I started by thinking: what’s the store? What are the products? What are the customers?

That grounding in observation and modeling helped me move fast and think clearly.

That day at Walmart was my real introduction to data modeling — not through theory, but through the physical world.

#3. “Thinking in Systems.”

When I started my career in the U.S., I worked on a loyalty analytics system — one of my first end-to-end data design projects.

I spent weeks sketching, refining, changing, and rebuilding the system. Every week, it looked different. One day, as I stepped into the elevator, my boss turned to me and said,

“I saw your design. You changed it completely from last week. That’s good. It means you’re thinking. Keep it going.”

That short elevator ride changed the way I viewed iteration. Until then, I thought redesigning meant I’d made a mistake. But his words reframed it — evolution is the process of engineering.

I started seeing every design review not as a checkpoint, but as a conversation.

Every new diagram was not a failure of the previous one, but an iteration toward clarity.

As we worked together more, he became my go-to mentor — not just for technical guidance, but for how to think. One day, over coffee, I asked him a question that had been on my mind:

“How do you cultivate architectural thinking?”

He smiled and gave me an unusual exercise.

He said, “Every day you walk from Montgomery Street to the Caltrain. It’s what — fifteen minutes? During that walk, observe how the city works. Watch how people who don’t know each other coordinate. Notice how traffic lights, signs, and signals function without central control. You’ll start to see the same patterns in our system design from emergent behaviour to the leader-follower model.”

It sounded odd, but I did it.

Each evening, I walked through downtown San Francisco — watching the rhythm of people, cars, and crosswalks. I noticed how one signal turning green in one intersection triggered waves of motion down the street. I saw bottlenecks at corners, retries when people crossed late, failovers when lights malfunctioned, and officers took control.

And suddenly, distributed systems weren’t abstract anymore. They were everywhere.

Humans, too, were part of a system — loosely coordinated, mostly independent, but connected through protocols, feedback, and flow.

That was the moment I truly understood system thinking — the ability to look beyond components and see interactions, dependencies, and evolution.

It also taught me humility: a good architect doesn’t impose order; they design for emergence. They build for change, not for perfection.

To this day, when I review a data platform design or a data flow diagram, I still imagine that walk from Montgomery Street to Caltrain. Systems are just cities — made of processes instead of people. Once you see it, you can’t unsee it.

#4. “Believing You Belong”

After I moved to the USA, I spent more time doubting myself than writing code.

Every meeting felt like an exam I hadn’t studied for. Every question felt like a test of belonging. I carried a quiet imposter syndrome — that whisper in your head that says you just got lucky.

One afternoon, my boss noticed my hesitation during a design review. After the meeting, he stopped me and said something simple that stayed with me forever:

“If you’re sitting here, you’re already good enough.”

It was a short sentence, but it landed deeply. There was no lecture, no performance review, no pep talk — just a fact. If you’re in the room, it’s because you earned it.

That moment changed how I carried myself. I realized confidence doesn’t come from knowing everything; it comes from recognizing that you’ve earned your seat — and you can grow from there.

I’ve repeated that same line to dozens of people since then — junior engineers, interns, even peers who were struggling to see their worth. Because the truth is, the data world can be intimidating. There’s always a new framework, a new paper, a new “modern” stack. You’ll never feel fully caught up.

But you don’t need to.

You need to keep showing up, keep learning, and keep thinking.

That sentence became the foundation for something else — it taught me that data engineering, at its core, is a confidence game. You’re constantly making decisions under uncertainty: what schema to use, how to partition data, how to handle scale. Doubt will paralyze you faster than a bad design.

Good engineers are not fearless; they just keep thinking despite fear.

Looking Back

When I look back now, I realize that everything I learned about data engineering started with a mindset shift, not a technical one.

  • Don’t chase money — chase knowledge. → Focus on curiosity; mastery compounds faster than rewards.
  • You’re thinking — keep it going. → Iterate relentlessly and observe systems beyond code.
  • Go to Walmart. → Learn to model the world in data.
  • If you’re sitting here, you’re good enough. → Believe in your ability to learn and grow.

The tools, frameworks, and clouds will keep changing. The mental models won’t.

Those mentors taught me that thinking like a data engineer is not about syntax or pipelines; it’s about curiosity, observation, and humility.

It’s about realizing that the best engineers don’t just build systems — they listen to them.

They watch how systems behave, evolve, and sometimes break — and they design with that reality in mind.

These lessons stayed with me — not as quotes to remember, but as ways of seeing the world.

So, if you’re early in your career or doubting your place in the data world, remember this:

You don’t need to know everything to think like a data engineer. You just need to keep observing, iterating, and thinking.

Because in the end, data engineering is less about moving data — and more about understanding how the world moves.

Closing Thoughts

If I had to summarize years of learning into one sentence, it would be this:

“Thinking like a data engineer is not about data. It’s about systems — human, technical, and everything in between.”

The world around you is the best classroom. Every store, street, and signal is a distributed system waiting to be understood. Every mistake is a feedback loop waiting to be improved. Every mentor is a node in your network of thought.

Keep learning. Keep thinking. And most importantly — keep observing.

Once you start seeing the world as data, you realize you've always been engineering it.