Music Forem

🚀 Exploring the Unknown: Building UAP Detector with MeDo

Michael G. Inso — Sun, 10 May 2026 11:03:40 +0000

🚀 Exploring the Unknown: Building UAP Detector with MeDo

The skies have always inspired wonder, but they also hold mysteries we’ve yet to explain. For the Build with MeDo Hackathon, we set out to create something bold: UAP Detector powered by MeDo — an immersive anomaly detection platform that blends AI precision, cyberpunk design, and community-driven exploration.

🌌 Inspiration

We wanted to build a tool that feels like mission control for the unexplained. Inspired by aerospace innovation, anomaly research, and the aesthetics of sci-fi, our vision was to merge scientific curiosity with artistic immersion.

🔍 What It Does

UAP Detector provides a multi-layered detection system:

📷 Camera-based anomaly detection with image/video capture
📡 Radar simulation with waveform visualization and anomaly blips
📊 Frequency spectrum scanning for electromagnetic disturbances
🗺️ Location-based logging with timestamps and geotags
💾 Secure storage & CSV export via Supabase

All wrapped in a cyberpunk-inspired dashboard with animated starfields, glitch effects, and holographic UI.

🧠 How We Built It

Platform: MeDo no-code AI builder for rapid prototyping
Database: Supabase for secure event storage and retrieval
Frontend: Custom CSS animations + MeDo modules for radar/frequency visualization
APIs: REST + JSON pipelines for modular data flow
Collaboration: GitHub for version control, CapCut/Dreamina for creative assets

⚙️ Challenges

Balancing scientific realism with immersive visuals
Ensuring real-time synchronization across detection modules
Optimizing UI for mobile performance without losing fidelity
Extending MeDo’s no-code environment with custom AI logic

🏆 Accomplishments

Built a fully functional detection dashboard in hackathon time
Designed a cinematic cyberpunk interface that feels futuristic
Achieved real-time anomaly visualization with radar + frequency overlays
Created a community-ready platform for enthusiasts and researchers

📚 What We Learned

The power of no-code AI platforms in accelerating innovation
How to merge data visualization with emotional design
The importance of UX storytelling in engaging users
Cross-disciplinary collaboration yields results that are both functional and artistic

🔮 What’s Next

🌍 Integration with satellite & weather data
📱 Mobile app with AR sky scanning
🌐 Community portal for collaborative anomaly tracking
🤖 AI model refinement with open datasets
✈️ Partnerships with aerospace & research organizations

💡 This project was #BuiltWithMeDo — a testament to how creativity and technology can converge to explore the unknown.

Hashtags:

BuiltWithMeDo #Hackathon #AI #Cyberpunk #DataVisualization #UAP #Innovation

_🔗Live Demo link: UAP Detector powered by MeDo
_

I shipped my mobile app to production. Key engineering decisions and sub-agents-based QA system.

Saar Ezagouri — Sun, 10 May 2026 11:02:28 +0000

Brief introduction

I’m a solo builder. I built Salute, a cross-platform mobile application focused on structured tracking of workouts, nutrition, and habits — the three core pillars for building a sustainable healthy lifestyle product.

In this post, I want to walk through some of the more significant technical and architectural decisions I made during the last months of development.

Building solo: slow is fast

Working alone changes the nature of execution. You are responsible for both system design and implementation, and every decision compounds quickly.

I tend to work in a highly time-aware way, optimizing small actions and switching contexts efficiently. But when building a full product solo, I had to shift priorities.

I followed a principle I learned from my Brazilian Jiu-Jitsu coach: technique first, then power. In practice, this translated to:

Prioritizing architecture before implementation
Spending time on system design and edge cases upfront
Mapping flows visually (I used Miro and physical sketches). Defining constraints and tech decisions early, but keeping flexibility where needed.
Although this approach felt slower at the beginning, it significantly reduced rework later and improved overall development speed.

Flutter for cross-platform development

One of the key decisions was using Flutter for cross-platform development.

While I did not perform a deep comparative evaluation with React Native in this project, Flutter proved to be stable and consistent across platforms in practice. The ecosystem was mature enough for all required features, and the community and documentation were reliable and structured.

Claude Code and sub-agent workflows

During the planning phase, I introduced sub-agent workflows as a core part of the development process.

I worked with Claude Code (and evaluated other tools such as Gemini Pro, GPT-based coding tools, FlutterFlow, and Firebase Studio), but found that a structured agent-based workflow provided the most control and reliability.

A key part of this system was building a knowledge layer:

Collecting official documentation and best practices from Flutter
Structuring them into modular “skills”
Maintaining a central instruction file (CLAUDE.md) containing architectural rules and coding standards
Adding platform-specific guidelines from Android (Material Design) and iOS (Human Interface Guidelines)

This created a reusable, structured context layer for the agents, improving consistency in UI/UX and architecture decisions.

Sub-agent QA system: a major productivity shift

One of the most impactful parts of the system was an agent-based QA pipeline.

As a solo developer, testing becomes a bottleneck. External beta testers help, but feedback cycles are slow and inconsistent. I needed a more deterministic system.

So I built an internal QA pipeline composed of multiple specialized agents:

Screeners

Each screener is responsible for a specific part of the application (e.g., onboarding flow). Their tasks include but not limited to:

UI/UX validation against platform guidelines
Identifying broken states or missing edge cases
Detecting unlocalized or inconsistent text
Verifying interaction behavior
Responsive and adaptive UI

They operate with direct access to the running app via MCP tools and the Dart SDK environment.

Validators

Validators review screener outputs and filter noise:

Remove false positives
Split overloaded screener tasks when necessary
Improve signal-to-noise ratio in reported issues

They do not modify the system, only verify findings.

Reviewers

Reviewers consolidate validated findings into structured reports:

Summarize issues per feature area
Refine or generate targeted improvement notes
Update or extend internal “skills” documentation when needed

They are responsible for turning raw findings into actionable engineering work - for the head agent.

Orchestrator

The orchestrator manages execution flow:

Screeners run first
Validators refine outputs
Reviewers structure the final reports
Implementation follows based on prioritized findings

A key aspect of making this system work in practice was carefully managing agent permissions and tool access. Each agent was given a very specific role, with tightly scoped responsibilities and minimal required context. This was important both for maintaining order in the workflow and for controlling token usage across the system. Overloading agents with broad access or unclear responsibilities quickly reduced efficiency and increased noise in the output, so strict separation of concerns and tool-level access control became a core design principle. When optimized - it works very good and saves priceless time.

Technical QA infrastructure

The QA system was built around a direct runtime connection to the Flutter application using the Dart SDK MCP server, which exposes the Dart Tooling Daemon (DTD) and flutter_driver capabilities to agents.

Each screener agent:

Launches the app in debug mode on an emulator
Connects to the Dart Tooling Daemon
Interacts with the live application through MCP tools

This includes:

UI interaction (taps, input, navigation, scrolling)
Widget tree inspection
Runtime log and error monitoring
Hot reload / hot restart cycles Because agents interact directly with the running app, there is no need for traditional test harness code.

I intentionally avoided integration_test due to both architectural constraints and known build issues (notably release-time dependency stripping of required libraries under R8, which can break plugin registration).

Outcome

This QA architecture significantly reduced manual testing overhead and improved iteration speed during development. For a solo builder, it effectively acted as a scalable internal QA team, without introducing heavy testing infrastructure.

Python and Its Role in Data Analytics: A Beginner-Friendly Guide Using Logistics Data

NelimaL — Sun, 10 May 2026 11:01:00 +0000

Introduction

In today’s digital economy, organizations generate huge amounts of data every single day. However, raw data alone is not useful unless businesses can analyze it and turn it into meaningful insights.

One of the most powerful tools used in data analytics today is Python. Python has become one of the most popular programming languages in the world because it is simple, powerful, flexible, and beginner-friendly.

Unlike some programming languages that are difficult for beginners to understand, Python uses readable syntax that looks almost like normal English.

What Is Python?

Python is a high-level programming language created by Guido van Rossum and released in 1991. It was designed to be simple, readable, and easy to learn.

A high-level language means programmers can write code using human-friendly commands instead of complicated machine instructions.

For example, displaying a message in Python only requires one line of code:

print("Hello world")

This simplicity is one of the main reasons Python is popular among beginners.

Python is also versatile. It can be used in many industries and fields such as: Data analytics, Data science, Artificial intelligence, Machine learning, Web development, Cybersecurity
and Software development

Why Python Is Popular in Data Analytics

Python has become one of the most widely used tools in the data analytics space for several reasons.

1. Python Is Easy to Learn

Python syntax is clean and readable.

For example:

age = 21

if age >= 18:
    print("Adult")
else:
    print("Minor")

Even beginners can understand what this code is doing.

2. Python Has Powerful Data Libraries

Python has many built-in libraries and external packages that make data analysis easier.

Instead of writing long and complicated code, analysts can use specialized libraries to complete tasks quickly.

Popular libraries include: Pandas, NumPy, Matplotlib, Seaborn and Scikit-learn
These libraries help analysts to:

Clean data
Analyze data
Create charts
Perform calculations
Build predictive models

3. Python Has a Large Community

Millions of people use Python worldwide. This means beginners can easily find: Tutorials, Documentation, YouTube videos, Coding forums and Online courses -If a beginner encounters an error, there is a high chance someone else has already solved the same problem online.

4. Python Handles Large Amounts of Data

Businesses often work with thousands or millions of rows of data.
Python can process large datasets efficiently and integrate with:

SQL databases
APIs
Excel files
Cloud platforms
Machine learning tools This makes Python valuable in modern organizations.

Python Libraries Used in Data Analytics

Python libraries are collections of pre-written code that help developers complete tasks faster.

1. Pandas

Pandas is one of the most important Python libraries for data analytics. It is mainly used for:

Reading data
Cleaning data
Filtering records
Grouping information
Performing calculations
Working with tables

Example: Loading a Logistics Dataset

Below is an example of loading the logistics dataset using Pandas.

import pandas as pd
url =
"https://raw.githubusercontent.com/NelimaL/LOGISTICS_DATA/refs/heads/main/LOGISTICS_MOCK_DATA%20(1).json"
df = pd.read_json(url)

Display first 5 rows by slicing

print(logistics_df[:5])

This code imports the logistics dataset and displays the first five rows.

2. NumPy

NumPy is used for numerical operations and mathematical calculations.

Example: Calculating Average Delivery Time

import numpy as np

delivery_times = [2, 3, 24, 13, 4]

average_time = np.mean(delivery_times)

print("Average Delivery Time:", average_time)

Output

Average Delivery Time: 9.2

3. Matplotlib

Matplotlib is used for creating charts and graphs.

Example: Visualizing Delivery Ratings

import matplotlib.pyplot as plt
ratings = [2, 5, 2, 3, 4]
plt.hist(ratings)
plt.title("Delivery Ratings")
plt.xlabel("Ratings")
plt.ylabel("Frequency")
plt.show()

This creates a histogram showing how delivery ratings are distributed.

4. Seaborn

Seaborn is another visualization library that creates more attractive statistical charts.

Example: Delivery Time vs Package Weight

import seaborn as sns
import matplotlib.pyplot as plt
sns.scatterplot(
    x=logistics_df["package_weight"],
    y=logistics_df["delivery_time"]
)
plt.title("Package Weight vs Delivery Time")
plt.show()

This chart helps analysts determine whether heavier packages take longer to deliver.

How Python Is Used to Clean Data

Real-world datasets are rarely perfect.
Data often contains:

Missing values
Duplicate records
Incorrect formats
Typing errors
Invalid values Data cleaning is one of the most important steps in analytics.

Checking for Missing Values

# Check missing values
print(logistics_df.isnull().sum())

This code checks how many missing values exist in each column.

Removing Duplicate Records

# Remove duplicates
logistics_df = logistics_df.drop_duplicates()
print("Duplicates removed")

Duplicate records can affect business reports and calculations.

Converting Date Columns

Dates are very important in analytics.

# Convert dates
logistics_df["delivery_date"] = pd.to_datetime(logistics_df["delivery_date"])
logistics_df["pickup_date"] = pd.to_datetime(logistics_df["pickup_date"])

This converts the columns into proper date format.

Checking Data Types

print(logistics_df.dtypes)

Understanding data types helps analysts know which operations can be performed.

How Python Is Used to Analyze Data

Once data is cleaned, analysts can start extracting insights.

Example 1: Counting Delivery Statuses

A logistics company may want to know how many deliveries were:

Delivered
Returned
In Transit
Out for Delivery

status_count = logistics_df["delivery_status"].value_counts()
print(status_count)

Example Output

Delivered           6
Returned            5
In Transit          4
Out for Delivery    5

This helps management monitor operational performance.

Example 2: Average Delivery Rating

average_rating = logistics_df["delivery_rating"].mean()

print("Average Delivery Rating:", average_rating)

Example Output

Average Delivery Rating: 3.4

This helps companies evaluate customer satisfaction.

Example 3: Finding the Fastest Deliveries

fastest_delivery = logistics_df.sort_values(
    by="delivery_time"
)

print(fastest_delivery[["tracking_number", "delivery_time"]].head())

This identifies packages delivered in the shortest time.

Example 4: Analyzing Delivery Companies

company_count = logistics_df["delivery_company"].value_counts()

print(company_count)

This shows how many deliveries each company handled.

Example 5: Average Package Weight

average_weight = logistics_df["package_weight"].mean()

print("Average Package Weight:", average_weight)

This helps logistics companies understand shipment trends.

How Python Is Used to Visualize Data

Data visualization helps analysts communicate findings clearly.

Instead of reading large tables, decision-makers can quickly understand charts and graphs.

Example 1: Bar Chart of Delivery Status

status_count = logistics_df["delivery_status"].value_counts()
status_count.plot(kind="bar")
plt.title("Delivery Status Distribution")
plt.xlabel("Delivery Status")
plt.ylabel("Count")
plt.show()

This chart shows the number of packages in each delivery status.

Example 2: Pie Chart of Delivery Ratings

rating_count = logistics_df["delivery_rating"].value_counts()
rating_count.plot(kind="pie", autopct="%1.1f%%")
plt.title("Delivery Ratings")
plt.ylabel("")
plt.show()

This chart helps visualize customer satisfaction levels.

Example 3: Line Graph of Delivery Time

logistics_df["delivery_time"].plot(kind="line")
plt.title("Delivery Time Trend")
plt.xlabel("Shipment Number")
plt.ylabel("Delivery Time")

plt.show()

This graph helps analysts identify delivery trends.

Real-World Uses of Python in Data Analytics

Python is used in many industries worldwide.

1. Logistics and Supply Chain

Logistics companies use Python to:

Track deliveries
Optimize delivery routes
Predict delays
Analyze delivery performance
Monitor customer satisfaction

Using the logistics dataset, analysts can identify common delivery failure reasons.

failure_reason = logistics_df[
    "delivery_failure_reason"
].value_counts()

print(failure_reason)

This helps companies reduce failed deliveries.

2. Banking Industry

Banks use Python for:

Fraud detection
Credit scoring
Customer analysis
Financial forecasting

Example:

transactions = [500, 12000, 300, 15000]

for amount in transactions:
    if amount > 10000:
        print("Suspicious transaction:", amount)

3. Healthcare Industry

Hospitals use Python to:

Analyze patient records
Predict diseases
Monitor patient recovery
Manage hospital operations

Example:

patients = {
    "John": 120,
    "Mary": 150,
    "James": 180
}

for patient, pressure in patients.items():
    if pressure > 140:
        print(patient, "has high blood pressure")

4. Retail Industry

Retail businesses use Python to:

Analyze customer purchases
Predict sales trends
Manage inventory
Recommend products Example:

products = [
    "Milk",
    "Bread",
    "Milk",
    "Eggs",
    "Milk"
]

print(products.count("Milk"))

To manageinventory

Why Beginners Should Learn Python

There are many reasons beginners should consider learning Python.

1. Python Is Beginner-Friendly

Python has simple syntax that makes programming easier to understand. Beginners can focus on solving problems instead of struggling with complicated rules.

2. Python Is Highly Marketable

Python skills are highly demanded in industries such as:

Data analytics
Artificial intelligence
Software engineering
Cybersecurity
Data science Professionals with Python skills often have strong career opportunities. ## 3. Python Supports Automation Python can automate repetitive tasks which saves time and increases efficiency. Example:

for report in range(1, 6):
    print("Generating Report", report)

4. Python Encourages Problem Solving

Learning Python improves logical thinking and problem-solving skills. This skill is valuable in many careers.

Challenges Beginners May Face

Although Python is beginner-friendly, learners may still experience challenges.

1. Understanding Programming Logic

Programming requires critical thinking and logical reasoning.

2. Learning Libraries

Libraries such as Pandas and NumPy can feel overwhelming at first.

3. Debugging Errors

Beginners often encounter syntax errors.
Example:

print("Hello"

The closing bracket is missing.
However, with practice, debugging becomes easier.

Tips for Learning Python Successfully

Practice Regularly-The more you practice, the more comfortable you become.

Build Real Projects-Projects help beginners apply what they learn.

Examples include:

Delivery tracking dashboards
Sales analysis projects
Expense trackers
Student performance analysis ## Learn Data Visualization-Visualization is one of the most valuable skills in analytics. Practice creating:
Bar charts
Pie charts
Histograms
Scatter plots ## Read Error Messages Carefully-Python error messages usually explain the problem. Understanding these messages helps learners improve faster. ## Use Real Data-Working with real datasets improves learning. The logistics dataset used in this article demonstrates how businesses analyze operational data using Python.

Conclusion

As businesses continue generating larger amounts of data, the demand for Python skills will continue growing. Beginners who start learning Python today are preparing themselves for exciting opportunities in the future of data analytics.

I Built an AI-Powered Daily LeetCode Planner in 2 Hours Using Workflow Automation

Rishabh — Sun, 10 May 2026 11:00:51 +0000

I Built an AI-Powered Daily LeetCode Planner Using Workflow Automation

Recently, I explored workflow automation using Kestra and ended up building a small but powerful system, an AI-powered Daily LeetCode Planner.

The goal was simple:

Stop wasting time deciding what to solve every day and automate the entire process.

What it does

Every morning, the system automatically:

Fetches coding problems from LeetCode
Selects a balanced set of Easy, Medium, and Hard questions
Sends them to an AI model for structured analysis
Generates a full study plan with patterns and hints
Emails it directly to me

Tech Stack

Kestra (workflow orchestration)
Python (data processing and logic)
Google Gemini API (AI analysis)
LeetCode GraphQL API (problem data source)
SMTP (email automation)

How the workflow works

1. Fetch problems

Pulls a list of 50 problems from LeetCode GraphQL API.

2. Select questions

A Python script:

Filters valid entries
Groups by difficulty
Randomly selects a balanced set

3. AI analysis

Gemini processes the selected questions and generates:

Solving patterns
Important concepts
One-line hints
Interview insights
Recommended solving order

4. Email output

The final structured plan is sent automatically to my email every morning.

Why I built this

As someone practicing DSA regularly, I noticed:

Time wasted choosing problems
No structured daily flow
No pattern-based learning system

So I automated it instead.

What I learned

This project taught me:

Workflow automation can connect full systems, not just scripts
AI is best used for structuring and reasoning, not just answers
Small automation pipelines can quickly become powerful tools
Debugging multi-step workflows is a different skill than normal coding

Flow YAML File (Github): https://github.com/rishabhrawat05/AI-Daily-LeetCode-Planner-Kestra

Your Walk Betrays You

Tim Green — Sun, 10 May 2026 11:00:00 +0000

You have never walked anonymously. You may have believed otherwise, pulling a hood over your head or choosing the busy side of the street, but the truth has been catching up for years. The way you shift your weight from one foot to the other, the cadence of your stride, the particular rhythm of your fingers on a keyboard, even the micro-fluctuations in your voice when you order a coffee: all of these patterns are, increasingly, as identifiable as your fingerprint. And unlike your fingerprint, you leave them everywhere, involuntarily, continuously, without ever pressing your thumb to glass.

Artificial intelligence systems can now identify individuals through subtle behavioural patterns and voice characteristics with startling accuracy. Gait recognition software deployed on the streets of Beijing and Shanghai can pick you out of a crowd from 50 metres away, even with your back turned and your face completely covered. Voice biometric systems in banking can authenticate your identity from a few seconds of speech. Wi-Fi signals bouncing off your body as you walk through a room can betray your identity through walls. The question is no longer whether these technologies work. It is what their proliferation means for the very concept of being unknown in a public space, and whether truly private human interaction remains possible in an age of pervasive, ambient identification.

The Expanding Biometric Frontier Beyond the Face

For over a decade, the surveillance debate has centred on facial recognition. Cities have banned it. Activists have marched against it. Researchers like Joy Buolamwini at the MIT Media Lab have exposed its profound racial biases, demonstrating through her landmark 2018 Gender Shades study that commercial facial analysis systems from IBM, Microsoft, and Face++ misclassified darker-skinned women at rates as high as 47 per cent while achieving error rates below 1 per cent for lighter-skinned men. Her work, co-authored with Timnit Gebru, catalysed a reckoning that led every audited US-based company to stop selling facial recognition technology to law enforcement by 2020.

But while the world was arguing about faces, a quieter revolution was unfolding. Behavioural biometrics, the science of identifying people through how they move, type, speak, and interact with the physical world, has advanced rapidly and without the same degree of public scrutiny. Unlike facial recognition, which requires a camera pointed at your face, behavioural biometrics can operate at a distance, through obstacles, and without the subject's knowledge or cooperation. This makes it, in many respects, a far more consequential threat to anonymity than the technology that has dominated headlines.

The gait biometrics market was valued at USD 1.25 billion in 2024 and is projected to reach USD 3.41 billion by 2032, growing at a compound annual growth rate of 13.38 per cent. Security agencies accounted for roughly 44 per cent of that market in 2024, with Asia-Pacific expected to see the fastest growth at 15.15 per cent annually through 2032. These are not speculative projections from fringe analysts; they reflect sustained investment by governments and corporations in technologies that identify you not by what you look like, but by what you do.

Gait Recognition Comes of Age

The idea that every person walks differently is not new. Forensic investigators have long known that gait is distinctive. What is new is the ability of AI systems to extract that distinctiveness from ordinary surveillance footage and match it against databases at scale.

The Chinese AI company Watrix, incubated by the Chinese Academy of Sciences, has developed gait recognition software that extracts a person's silhouette from video and analyses its movement to create a model of how that person walks. According to Watrix CEO Huang Yongzhen, the technology has been trialled by police in Beijing, Shanghai, and Chongqing, and a pilot system operates in Hubei and Guangdong provinces. The system can identify individuals from up to 50 metres away, from any angle, even when faces are covered and in darkness. “With facial recognition people need to look into a camera,” Huang told the South China Morning Post. “Cooperation is not needed for them to be recognised by our technology.”

The accuracy Watrix claims is striking: up to 96 per cent. The company, which was inspired by a US Defence Advanced Research Projects Agency (DARPA) study, has been in discussions with security firms in Singapore, India, Russia, the Netherlands, and the Czech Republic. Security officials in China's Xinjiang province, where the Uyghur Muslim population faces intense surveillance, have also expressed interest. The technology is not merely supplementary to existing surveillance; it fills the gaps that facial recognition cannot reach. It operates in conditions where faces are obscured, where lighting is poor, and where subjects are unaware they are being watched. Every person's posture, Huang has stated, is unique, like a fingerprint, and gait recognition is capable of identifying targets from any angle.

Nor is Watrix alone. In September 2024, NEC Corporation launched a gateless biometric authentication system capable of authenticating 100 people per minute while they are in motion. The system, initially deployed at NEC's Tokyo headquarters in July 2024, combines face recognition with gait-based matching technology to identify individuals in crowded areas without requiring them to stop or present credentials. NEC, which has been ranked first in face recognition benchmark tests by the US National Institute of Standards and Technology since 2009, has deployed its biometric technology in more than 50 countries and across 80 airports globally. The new system is being offered in Japan, the United States, and Singapore, and uses deep learning to re-identify tracked individuals even after they pass behind obstructions or through dense crowds.

The Voice That Gives You Away

Your voice is another behavioural signature that AI systems are learning to read with uncomfortable precision. Voice biometrics analyse characteristics including pitch, tone, cadence, and the physical properties of your vocal tract to create a unique voiceprint. Financial institutions have been early adopters: customers can authenticate transactions simply by speaking. The technology is marketed as frictionless and secure, a way to eliminate passwords and PINs. But a voiceprint, once captured, is not a password. It cannot be changed if compromised. And the infrastructure for capturing voice data is already ubiquitous: every smartphone, every smart speaker, every customer service line.

But the same technology that verifies your identity can also compromise it. Voice recordings are biometric identifiers as sensitive as fingerprints or retinal scans, yet they can be captured from a distance, harvested from voicemail messages, or scraped from social media posts. According to the 2024 Javelin Identity Fraud Study, American consumers lost more than USD 47 billion to identity fraud that year, with AI-generated synthetic identity fraud and voice cloning driving much of that figure. A survey by BioCatch found that 91 per cent of US banks are reconsidering voice biometric authentication due to AI cloning risks.

The threat is not theoretical. In April 2025, Hong Kong police dismantled a deepfake scam ring that used AI-generated video and cloned voice attacks to open accounts at HSBC, resulting in losses exceeding HK 1.5 billion, approximately USD 193.2 million. The UK government has published a briefing note on the ethical issues arising from public sector use of biometric voice recognition technology, acknowledging the tensions between convenience, security, and privacy. Some institutions store biometric voice templates indefinitely or share them with third-party vendors for AI training purposes, often without the knowledge of the individuals whose voices are on file.

The US Department of Justice has affirmed a broad definition of biometric identifiers that encompasses facial images, voiceprints and patterns, retina and iris scans, palm and fingerprints, and behavioural data such as gait and keyboard usage patterns. This definitional expansion matters because it signals that regulators are beginning to recognise what technologists have known for some time: the body is a broadcasting device, and everything it broadcasts can be recorded, analysed, and matched to an identity.

The Invisible Biometric Layer

Beyond gait and voice, there exists an entire category of behavioural biometrics that most people never consider. Keystroke dynamics, the study of how you type, can identify individuals based on the timing between key presses, the duration for which each key is held, and the rhythm of your overall typing pattern. These measurements, captured at millisecond precision, create a biometric template that is unique to each person and extremely difficult to replicate.

Research published in Discover Applied Sciences in 2025 highlights that keystroke dynamics can be used for continuous, real-time authentication, with any deviation from established typing patterns triggering an alert for possible unauthorised access. A 2024 study published in Sensors demonstrated that deep learning architectures combining convolutional and recurrent neural networks achieve high effectiveness in identifying users based on typing patterns. Forensic applications are also emerging: regardless of the number of machines a person uses, their typing pattern persists, making keystroke dynamics a potential tool for identifying anonymous online activity.

The transparency of this technology is part of what makes it so consequential. Keystroke dynamics require no specialised hardware. They operate via backend software implementation, and in most cases users are entirely unaware they are being profiled. This passive, invisible collection of behavioural data represents a fundamentally different kind of surveillance from a camera on a pole or a guard at a door. It is ambient, continuous, and nearly impossible to evade. Research from MDPI in 2023 also found that keystroke authentication is influenced by the language being typed, meaning bilingual users produce distinct profiles for each language, further enriching the data available for identification.

Wi-Fi Signals as a Surveillance Medium

Perhaps the most unsettling frontier in behavioural identification is the use of ordinary Wi-Fi signals to detect, track, and identify people. Wi-Fi sensing exploits the way radio signals interact with human bodies: as you move through a space, you cause reflections, refractions, and attenuations in the Wi-Fi signal, and these disturbances encode information about your body shape, movement patterns, and activities.

A comprehensive 2024 survey published in ACM Transactions on Sensor Networks documents how researchers have used Channel State Information from Wi-Fi signals to identify individuals based on their unique gait patterns, achieving accuracy rates above 90 per cent. Unlike camera-based systems, Wi-Fi sensing works through walls, in complete darkness, and without requiring any device to be carried by the subject. The technology leverages existing infrastructure, requiring only standard Wi-Fi access points and receiving devices.

Research published in Engineering Applications of Artificial Intelligence demonstrated human activity recognition through walls using deep learning models applied to Wi-Fi CSI data. The PA-CSI model, which combines phase and amplitude analysis with attention mechanisms, has achieved accuracy rates of up to 99.9 per cent on benchmark datasets. A specialised system called WiFind can detect, localise, and estimate body pose through walls, debris, and smoke, using nodes costing under USD 150 each.

The implications are stark. A person walking through a building equipped with standard Wi-Fi infrastructure could, in principle, be continuously tracked and identified without any visible surveillance equipment, without their knowledge, and without any possibility of covering their face or altering their appearance to avoid detection. Wi-Fi technology has evolved from its initial 802.11 standard to Wi-Fi 6 and the anticipated Wi-Fi 7, with each generation improving the resolution and sensitivity of sensing capabilities. The physical world is becoming readable in ways that were previously confined to science fiction.

Regulation Struggles to Keep Pace

The regulatory response to behavioural biometric surveillance has been fragmented and reactive, consistently trailing the technology it seeks to govern. The most significant legislative development has been the European Union's AI Act (Regulation (EU) 2024/1689), which entered into force on 1 August 2024 and began enforcing prohibitions on certain AI systems from 2 February 2025.

Article 5 of the AI Act prohibits real-time remote biometric identification systems in publicly accessible spaces for law enforcement, with limited exceptions. It bans AI systems that scrape facial images from the internet or CCTV footage, and prohibits biometric categorisation systems that deduce race, political opinions, religious beliefs, or sexual orientation from biometric data. Violations carry fines of up to 35 million euros or 7 per cent of global annual turnover, whichever is higher.

Yet the Act contains significant exceptions for law enforcement, allowing real-time biometric identification for targeted searches of victims of abduction or trafficking, prevention of imminent threats, and prosecution of serious crimes, all subject to judicial authorisation. These carve-outs have drawn criticism from organisations like European Digital Rights (EDRi), which argues they may legitimise the very practices the Act purports to ban. As a Stanford Law School analysis noted, despite omitting an outright ban on facial recognition in publicly accessible spaces, the AI Act will probably show its full potential in the years after its entry into force.

In the United States, Illinois' Biometric Information Privacy Act remains the strongest state-level protection, granting individuals a private right of action and statutory damages of USD 1,000 per negligent violation and USD 5,000 per intentional violation. BIPA class action settlements totalled more than USD 206 million in 2024, including the landmark Clearview AI settlement in which class members received a 23 per cent equity stake in the company, valued at approximately USD 51.75 million. In August 2024, Illinois amended BIPA to limit damages to one violation per person regardless of how many times data was collected, a change that contributed to a sharp decline in new filings. Clearview AI itself had amassed a database of more than 60 billion facial images scraped from social media platforms, news websites, and other publicly accessible online sources, prompting the wave of litigation.

San Francisco became the first US city to ban government use of facial recognition in May 2019, with Supervisor Aaron Peskin declaring, “We all support good policing but none of us want to live in a police state.” Yet even this landmark ordinance had limits: it carved out exceptions for federal facilities and did not apply to private businesses. Moreover, in the five years since the ban, San Francisco police admitted to circumventing it on six separate occasions.

The UK's Information Commissioner's Office launched its AI and biometrics strategy in June 2025, focusing on situations where risks are highest and public concern is clearest. The ICO plans to set a high threshold of lawfulness for AI systems that infer subjective traits, intentions, or emotions based on physical or behavioural characteristics. Public polling cited in the strategy found that 54 per cent of UK adults have concerns about facial recognition technology impacting civil liberties, and that concern about AI use for welfare eligibility has risen from 44 per cent to 59 per cent between 2022 and 2025.

When the Wrong Person Gets Caught

The dangers of these systems are not abstract. In January 2020, Robert Williams, a Black man living in Farmington Hills, Michigan, was arrested outside his home in front of his wife and two young daughters by Detroit police. He was detained for thirty hours in an overcrowded, dirty cell. The arrest was based on a facial recognition match from a blurry surveillance image of a shoplifting suspect at a Shinola store in Detroit. Williams was actually the ninth-best match in the system's results, and detectives had not investigated his whereabouts before making the arrest.

Williams' case, brought to public attention by the ACLU and the University of Michigan Law School's Civil Rights Litigation Initiative, became the first publicly reported instance of a false facial recognition match leading to a wrongful arrest. On 28 June 2024, the parties reached a groundbreaking settlement that established the nation's strongest police department policies constraining law enforcement's use of facial recognition, including a prohibition on arrests based solely on facial recognition results and mandatory training on the technology's risks and its higher misidentification rates for people of colour.

Williams' case was one of three known wrongful arrests in Detroit where police relied on facial recognition technology. All three individuals wrongfully arrested were Black. This pattern underscores the findings of Buolamwini's Gender Shades study and raises a critical question about behavioural biometrics more broadly: if the training data and deployment contexts of gait recognition, voice identification, and other behavioural systems reproduce the same biases, the consequences for marginalised communities could be severe. The Pew Research Center found in a 2022 survey that 28 per cent of Black adults said police would definitely make more false arrests if facial recognition were widely adopted, compared with just 11 per cent of white adults.

Surveillance and the Death of Free Assembly

The surveillance theorist and Harvard professor Shoshana Zuboff has described surveillance capitalism as “the unilateral claiming of private human experience as free raw material for translation into behavioural data.” Her framework, articulated in The Age of Surveillance Capitalism (2019), identifies a fundamental shift in which human experiences are extracted, computed, and sold as prediction products. “We are not surveillance capitalism's 'customers,'” Zuboff writes. “We are the sources of surveillance capitalism's crucial surplus.”

When behavioural identification systems operate in public spaces, they do not merely observe; they transform public space itself. Research consistently demonstrates that surveillance produces measurable “chilling effects” on freedom of expression, assembly, and political participation. A qualitative study published in the Journal of Human Rights Practice (Oxford Academic) documented, through interviews with 44 participants in Uganda and Zimbabwe, how the fear of surveillance undermines trust and interpersonal relationships, creating spirals of paranoia and mistrust that directly affect the right to freedom of assembly.

These findings extend well beyond authoritarian contexts. In the United States, the Department of Commerce's National Telecommunications and Information Administration found in a survey of 41,000 households that one in five Americans avoided online activity because of concerns about government data collection. The Electronic Frontier Foundation has highlighted studies showing that government surveillance discourages both speech and access to information on the internet. When people know they are being watched, they change what they say, where they go, and whom they associate with. The extension of these chilling effects from the digital to the physical realm, through gait recognition cameras, voice identification microphones, and Wi-Fi sensing systems, represents a qualitative escalation.

Amnesty International's Ban the Scan campaign, launched in 2021, has mapped the surveillance landscape of New York City, documenting more than 25,500 CCTV cameras across the city and revealing that the NYPD used facial recognition technology in 22,000 cases since 2017. The campaign found that the most surveilled neighbourhood across three boroughs was an area in Brooklyn with a population comprising 54.4 per cent Black residents, underscoring the racialised geography of surveillance infrastructure. Amnesty further documented how facial recognition was used at Black Lives Matter protest sites in 2020 to identify, track, and harass people exercising their rights to peaceful assembly.

The UN Office of the High Commissioner for Human Rights is preparing a thematic report, expected at the 62nd session of the Human Rights Council, analysing the impact of digital and AI-assisted surveillance on assembly and association rights, including chilling effects. A 2025 study in Big Data and Society, examining Extinction Rebellion protests in The Hague, revealed that surveillance technology produces effects beyond traditional chilling, including what researchers termed “hyper-transparency” and “hyper-alertness” among both protesters and police.

The Rise of Anti-Surveillance Fashion

The proliferation of behavioural identification systems has given rise to a counter-movement that sounds like it belongs in a cyberpunk novel but is entirely real: adversarial fashion. These are garments, accessories, and cosmetic techniques designed to confuse, disrupt, or defeat AI surveillance systems.

Artist and researcher Adam Harvey pioneered this field with his CV Dazzle project in 2010, which used cubist-inspired makeup patterns to defeat facial detection algorithms. The technique, named after the dazzle camouflage developed by British painter Norman Wilkinson for Allied ships during the First World War, works by obscuring key facial features until recognition systems can no longer detect a human face. Harvey followed this with HyperFace in 2016, which takes the opposite approach: rather than hiding faces, it floods the environment with false face-like patterns printed on fabric, exploiting algorithms' preference for the highest-confidence facial region.

More recently, the Italian company Cap_able has developed a patented process that algorithmically generates adversarial patterns, translating them into knitted garments that retail between USD 300 and USD 600. These garments combine visual adversarial patterns with infrared protection, aiming to disrupt both optical and thermal surveillance. Researchers have also published work on thermally activated dual-modal adversarial clothing that can defeat both visible-light cameras and infrared sensors simultaneously.

However, as technologist Adam Harvey himself has cautioned, “Camouflage, in general, should be considered temporary, but especially technical camouflage that targets quickly evolving algorithms.” The arms race between surveillance systems and countermeasures is inherently asymmetric: updating a neural network is cheaper and faster than redesigning a wardrobe. Moreover, the very act of wearing obviously adversarial clothing in a public space draws human attention, potentially marking the wearer as suspicious even as it confuses the machines.

The video surveillance industry, enhanced by AI, is projected to grow from USD 3.90 billion in 2024 to USD 12.46 billion by 2030, according to market research. Against this scale of investment, adversarial fashion remains a niche countermeasure, meaningful as a statement of resistance but limited as a practical solution to the erosion of anonymity.

Europe's Border Experiment in Behavioural Biometrics

While much of the debate about behavioural biometrics focuses on domestic surveillance, the technology is also reshaping the boundaries of national security and border control. The European Union's PopEye project, funded through a Horizon Europe grant of 3.2 million euros, represents a significant step towards integrating gait recognition into border security infrastructure.

PopEye, an acronym for “robust Privacy-preserving biOmetric technologies for Passengers' identification and verification at EU external borders maximising the accuracY, reliability and throughput of the rEcognition,” aims to identify individuals on the move, at distances of up to 200 metres, without requiring them to stop. The project combines gait recognition with 3D facial recognition, addressing the limitations of each technology when used in isolation.

The project follows a 2021 Frontex study that examined gait recognition in depth, suggesting that video, radar, and floor sensors could be used to identify people by how they walk. Led by the European Association for Biometrics, PopEye involves partners including the AIT Austrian Institute of Technology, Idiap Research Institute, KU Leuven, and Vrije Universiteit Brussel, among others. Pilot programmes are being conducted at the external borders of Romania and Finland, with the Finnish Ministry of Interior and Romanian Border Authorities serving as key participants.

The project's emphasis on privacy preservation and compliance with the EU's AI Act and GDPR reflects an awareness that the technology it develops operates in a sensitive legal and ethical space. Researchers from VUB and KU Leuven are leading efforts on integrated impact assessments to safeguard human rights and data protection. Yet the fundamental tension remains: a system designed to identify people at a distance, without their cooperation, is inherently a surveillance technology, regardless of the procedural safeguards that surround it.

The Economics of Knowing Who You Are

The security technologist Bruce Schneier, a fellow and lecturer at Harvard's Kennedy School and board member of the Electronic Frontier Foundation, has written extensively about the economics of surveillance and the asymmetries of power it creates. “It is poor civic hygiene to install technologies that could someday facilitate a police state,” Schneier has warned. He has illustrated the collapsing cost of surveillance with a telling comparison: covert human surveillance of an individual costs approximately USD 175,000 per month, while obtaining location information from a mobile provider costs as little as USD 30 per month.

Behavioural biometrics push this economic logic further still. Gait recognition can operate using existing CCTV infrastructure. Keystroke dynamics require only software. Wi-Fi sensing leverages networks that are already installed in virtually every commercial and institutional building. The marginal cost of identifying one additional person approaches zero, which means the economic incentive to deploy these systems is enormous and the barriers to mass deployment are vanishingly small.

This economic reality creates what Schneier has called an alliance of interests between corporate and government surveillance. Corporations collect behavioural data for authentication, fraud prevention, and customer profiling. Governments seek the same data for security, immigration enforcement, and law enforcement. The data collected for one purpose inevitably becomes available for others, a phenomenon that privacy advocates call “function creep.” The US Consumer Financial Protection Bureau has already issued guidance stating that biometric information, including keystroke frequency and behavioural monitoring, used in employment decisions must comply with the Fair Credit Reporting Act.

Zuboff's analysis cuts deeper. She argues that “the power to predict human behaviour is the power to modify human behaviour, and this is what surveillance capitalism is all about.” When every public interaction can be linked to a known identity through behavioural patterns, the entire notion of a public sphere where individuals can move, speak, and associate without being tracked becomes an anachronism. The right to privacy, she insists, is not merely about data protection; it is about the conditions necessary for human autonomy: “what should become data in the first place, that is where the line has to be drawn.”

What Remains of Anonymity

The question this article set out to address, what does the rise of AI behavioural recognition mean for anonymity in public spaces, has a disquieting answer. The technological trajectory is clear: identification systems are becoming cheaper, more accurate, more pervasive, and harder to evade. They are moving beyond the face into the body's every motion and utterance. They work through walls, in darkness, and across distances that make consent meaningless.

The regulatory response, while significant in certain jurisdictions, remains fragmented and reactive. The EU's AI Act represents the most comprehensive attempt at governance, but its exceptions for law enforcement create significant loopholes. BIPA has produced substantial financial penalties in the United States, but it is a single state's law, and its recent amendments have blunted its deterrent effect. The UK's ICO strategy is still in its early stages. Globally, there is no coherent framework for governing technologies that can identify people from their walk, their voice, or the way they type.

What is at stake is not merely a technical question about privacy settings or data policies. It is a question about the kind of society that emerges when public spaces become zones of continuous, ambient identification. Research on the chilling effects of surveillance demonstrates that when people believe they are being watched, they modify their behaviour, self-censor their speech, and withdraw from political participation. The extension of surveillance from visible cameras to invisible behavioural identification systems does not reduce this effect; it amplifies it, because there is no way to know when you are and are not being observed.

Truly private human interaction in public spaces, a conversation with a stranger that no system records, a protest march where participants cannot be individually identified, a walk through a city where your movements are not logged and matched against a database, is becoming technologically impossible. This does not mean it will vanish entirely; enforcement gaps, technical limitations, and deliberate resistance will preserve pockets of anonymity. But the default condition of public life is shifting, from one where anonymity was assumed to one where identification is the norm.

The technologies being installed today will outlast the political conditions under which they were deployed. Gait recognition cameras placed for counter-terrorism will not be removed when the threat recedes. Voice identification systems built for banking will not be dismantled when fraud declines. Wi-Fi sensing capabilities embedded in building infrastructure will persist indefinitely. The question is not whether these technologies will be misused, but when, by whom, and with what consequences for the freedoms that depend on the ability to move through the world unrecognised.

Bruce Schneier put it plainly: “Privacy protects us from abuses by those in power, even if we're doing nothing wrong at the time of surveillance.” In a world where your walk, your voice, and your keystrokes are all that stand between you and identification, that protection is being quietly, systematically, irreversibly eroded.

References and Sources

Joy Buolamwini and Timnit Gebru. “Gender Shades: Intersectional Accuracy Disparities in Commercial Gender Classification.” Proceedings of Machine Learning Research, Vol. 81, 2018. http://proceedings.mlr.press/v81/buolamwini18a/buolamwini18a.pdf
South China Morning Post. “Chinese police test gait-recognition technology from AI start-up Watrix that identifies people based on how they walk.” November 2018. https://www.scmp.com/tech/start-ups/article/2187600/chinese-police-surveillance-gets-boost-ai-start-watrix-technology-can
NEC Corporation. “NEC Launches new system using Biometric Authentication Technology.” Press Release, 3 September 2024. https://www.nec.com/en/press/202409/global_20240903_01.html
GlobeNewsWire/SNS Insider. “Gait Biometrics Market Size to Hit USD 3.41 Billion by 2032.” 21 July 2025. https://www.globenewswire.com/news-release/2025/07/21/3118758/0/en/Gait-Biometrics-Market-Size-to-Hit-USD-3-41-Billion-by-2032-at-13-38-CAGR-Research-by-SNS-Insider.html
European Parliament. “EU AI Act: first regulation on artificial intelligence.” https://www.europarl.europa.eu/topics/en/article/20230601STO93804/eu-ai-act-first-regulation-on-artificial-intelligence
Stanford Law School. “No. 91: EU Artificial Intelligence Act: Regulating the Use of Facial Recognition Technologies in Publicly Accessible Spaces.” https://law.stanford.edu/publications/no-91-eu-artificial-intelligence-act-regulating-the-use-of-facial-recognition-technologies-in-publicly-accessible-spaces/
WilmerHale. “Year in Review: 2024 BIPA Litigation Takeaways.” 19 February 2025. https://www.wilmerhale.com/en/insights/blogs/wilmerhale-privacy-and-cybersecurity-law/20250219-year-in-review-2024-bipa-litigation-takeaways
Bloomberg Law. “Clearview AI Gets Settlement Approved in Face-Scan Privacy Case.” 2025. https://news.bloomberglaw.com/litigation/clearview-ai-gets-settlement-approved-in-face-scan-privacy-case
CNN. “San Francisco just banned facial-recognition technology.” 14 May 2019. https://www.cnn.com/2019/05/14/tech/san-francisco-facial-recognition-ban
SF Standard. “SFPD skirted facial-recognition ban, lawsuit says.” 18 July 2024. https://sfstandard.com/2024/07/18/san-francisco-police-facial-recognition-violations/
ACLU. “Williams v. City of Detroit.” https://www.aclu.org/cases/williams-v-city-of-detroit-face-recognition-false-arrest
Shoshana Zuboff. The Age of Surveillance Capitalism: The Fight for a Human Future at the New Frontier of Power. PublicAffairs, 2019.
Oxford Academic. “Chilling Effects of Surveillance and Human Rights: Insights from Qualitative Research in Uganda and Zimbabwe.” Journal of Human Rights Practice, Vol. 16, Issue 1, 2024. https://academic.oup.com/jhrp/article/16/1/397/7234270
Amnesty International. “Ban The Scan New York City.” https://banthescan.amnesty.org/nyc/index.html
Storbeck, M. et al. “Surveillance experiences of extinction rebellion activists and police: Unpacking the technologization of Dutch protest policing.” Big Data & Society, 2025. https://journals.sagepub.com/doi/10.1177/20539517241307892
ICO. “Preventing harm, promoting trust: our AI and biometrics strategy.” June 2025. https://ico.org.uk/about-the-ico/our-information/our-strategies-and-plans/artificial-intelligence-and-biometrics-strategy/
ACM Transactions on Sensor Networks. “A Survey on WiFi-based Human Identification: Scenarios, Challenges, and Current Solutions.” 2024. https://dl.acm.org/doi/10.1145/3708323
ScienceDirect. “WiFi-based human activity recognition through wall using deep learning.” Engineering Applications of Artificial Intelligence, 2024. https://www.sciencedirect.com/science/article/abs/pii/S0952197623013556
Springer Nature. “Keystroke dynamics for intelligent biometric authentication with machine learning.” Discover Applied Sciences, 2025. https://link.springer.com/article/10.1007/s42452-025-07449-5
MDPI/Applied Sciences. “Authentication by Keystroke Dynamics: The Influence of Typing Language.” 2023. https://www.mdpi.com/2076-3417/13/20/11478
Bruce Schneier. “The Eternal Value of Privacy.” Schneier on Security, May 2006. https://www.schneier.com/essays/archives/2006/05/the_eternal_value_of.html
Biometric Update. “PopEye to strengthen EU border biometrics with gait recognition integration.” October 2024. https://www.biometricupdate.com/202410/popeye-to-strengthen-eu-border-biometrics-with-gait-recognition-integration
Mozilla Foundation. “How to Disappear: The Rise of Anti-Surveillance Fashion.” https://www.mozillafoundation.org/en/nothing-personal/anti-surveillance-fashion-privacy-ai/
GOV.UK. “Briefing note on the ethical issues arising from the public sector use of biometric voice recognition technology.” https://www.gov.uk/government/publications/public-sector-use-of-biometric-voice-recognition-technology-ethical-issues/
Pew Research Center. “Public views of police use of facial recognition technology.” 17 March 2022. https://www.pewresearch.org/internet/2022/03/17/public-more-likely-to-see-facial-recognition-use-by-police-as-good-rather-than-bad-for-society/

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

Synchronous vs Asynchronous JavaScript

Pratham — Sun, 10 May 2026 10:53:26 +0000

Why JavaScript doesn't just wait around — and how that changes everything about how you write code.

Let me tell you about the moment asynchronous JavaScript broke my brain.

I wrote this code, fully expecting it to print in order:

console.log("First");
setTimeout(() => console.log("Second"), 0);
console.log("Third");

I expected: First → Second → Third.

I got: First → Third → Second.

Zero milliseconds of delay, and "Second" still printed last. I stared at my screen thinking JavaScript was broken. It wasn't. I just didn't understand how JavaScript handles time.

This is the story of synchronous vs asynchronous code, and once you get it, a massive amount of JavaScript behavior suddenly makes sense. Let me walk you through it the way it finally clicked for me in the ChaiCode Web Dev Cohort 2026.

What Does Synchronous Code Mean?

Synchronous means "one thing at a time, in order." Each line waits for the previous line to finish before it starts.

Think of it like a single-lane road. Only one car can pass at a time. If the car in front stops, everyone behind it waits.

console.log("Step 1: Wake up");
console.log("Step 2: Brush teeth");
console.log("Step 3: Make coffee");
console.log("Step 4: Start coding");

Output:

Step 1: Wake up
Step 2: Brush teeth
Step 3: Make coffee
Step 4: Start coding

Each line runs, finishes, and then the next one starts. Predictable. Linear. No surprises.

Synchronous Execution Timeline

Time →
─────────────────────────────────────────────────

  Step 1       Step 2       Step 3       Step 4
  ┌─────┐     ┌─────┐     ┌─────┐     ┌─────┐
  │Wake │ ──→ │Brush│ ──→ │Make │ ──→ │Code │
  │ up  │     │teeth│     │coffee│    │     │
  └─────┘     └─────┘     └─────┘     └─────┘

Each task COMPLETES before the next one STARTS.
Nothing runs in parallel.

This is how JavaScript works by default. It's a single-threaded language — it has one call stack, one thread, and it processes one operation at a time.

The Problem: Blocking Code

Synchronous execution works perfectly until you hit a task that takes time. Not a millisecond — real time. Seconds. Maybe longer.

Real-World Example: Waiting for Data

Imagine you're building a web app. You need to:

Show a loading message
Fetch user data from an API (takes 2–3 seconds)
Display the user data
Show other page content

If everything is synchronous:

Time →
─────────────────────────────────────────────────

  Show        Fetch data       Display      Show
  loading     (waiting...)     user data    content
  ┌─────┐    ┌────────────────┐ ┌─────┐    ┌─────┐
  │     │ ──→│  2-3 SECONDS   │→│     │ ──→│     │
  │     │    │  EVERYTHING    │ │     │    │     │
  │     │    │  IS FROZEN     │ │     │    │     │
  └─────┘    └────────────────┘ └─────┘    └─────┘
                     ↑
              BLOCKING! 🚫
              Nothing else can run while waiting.

The entire page freezes. The user can't scroll, can't click, can't do anything. The UI is unresponsive for 2–3 seconds. That's a terrible user experience.

This is called blocking — one slow task blocks everything else from running.

Code Example of Blocking

console.log("Page is loading...");

// Simulating a blocking operation (DON'T do this in real code)
const start = Date.now();
while (Date.now() - start < 3000) {
  // Busy-wait for 3 seconds — blocks EVERYTHING
}

console.log("Data loaded!");
console.log("Showing rest of the page");

During those 3 seconds, JavaScript can't do anything else. No animations, no button clicks, no rendering. The browser might even show the "page unresponsive" dialog.

What Does Asynchronous Code Mean?

Asynchronous means "start a task, move on, and come back to it when it's done." You don't wait — you continue doing other things.

Think of it like ordering food at a restaurant. You place your order and then continue your conversation while the kitchen prepares the food. When the food is ready, the waiter brings it to you. You didn't freeze in silence staring at the kitchen door for 20 minutes.

SYNCHRONOUS (blocking):
  You order → you STARE at the kitchen → food arrives → you eat → you talk

ASYNCHRONOUS (non-blocking):
  You order → you TALK while kitchen cooks → food arrives → you eat
  (you didn't waste time waiting)

In JavaScript, asynchronous code lets you say: "Start this task. I'll keep running other code. Call me when you're done."

Why JavaScript Needs Asynchronous Behavior

JavaScript runs in the browser. Browsers need to do a lot at the same time:

Respond to user clicks
Render animations smoothly (60 fps)
Fetch data from APIs
Run your JavaScript code
Update the DOM

If JavaScript blocked on every slow operation, the browser would freeze constantly. That's unacceptable for a web environment. So JavaScript uses an asynchronous model to handle time-consuming tasks without freezing the main thread.

The slow tasks get offloaded. While they're being processed elsewhere (by the browser, the network, the filesystem), JavaScript keeps running the rest of your code. When the slow task finishes, a callback is queued up and JavaScript processes it when it's free.

Asynchronous Examples: Timers and API Calls

`setTimeout` — The Simplest Async Example

console.log("Start");

setTimeout(() => {
  console.log("This runs after 2 seconds");
}, 2000);

console.log("End");

Output:

Start
End
This runs after 2 seconds

Wait — "End" printed before the timeout message, even though the timeout line comes first in the code! Here's why:

console.log("Start") runs immediately.
setTimeout registers the callback and says "run this after 2 seconds." JavaScript doesn't wait — it moves on.
console.log("End") runs immediately.
After 2 seconds, the callback fires: console.log("This runs after 2 seconds").

The Zero-Delay Mystery (Explained!)

Remember my opening example?

console.log("First");
setTimeout(() => console.log("Second"), 0);
console.log("Third");

Output: First → Third → Second.

Even with 0 milliseconds delay, the callback doesn't run immediately. It gets placed in the task queue and only executes after all synchronous code has finished. JavaScript always finishes what's on its plate before checking the queue.

`setInterval` — Repeat at Intervals

let count = 0;

const timer = setInterval(() => {
  count++;
  console.log(`Tick ${count}`);

  if (count === 3) {
    clearInterval(timer);
    console.log("Timer stopped.");
  }
}, 1000);

console.log("Timer started — code continues running...");

Output:

Timer started — code continues running...
Tick 1       (after 1 second)
Tick 2       (after 2 seconds)
Tick 3       (after 3 seconds)
Timer stopped.

The code after setInterval runs immediately. The ticks happen in the background.

API Calls with `fetch` (Preview)

console.log("Fetching user data...");

fetch("https://jsonplaceholder.typicode.com/users/1")
  .then((response) => response.json())
  .then((user) => {
    console.log(`User: ${user.name}`);
  });

console.log("This runs while fetch is working...");

Output:

Fetching user data...
This runs while fetch is working...
User: Leanne Graham       (arrives later)

fetch doesn't block. It fires the request, and JavaScript keeps going. When the response comes back, the .then() callback handles it.

The Asynchronous Task Queue Concept

Here's the mental model that ties everything together:

┌──────────────────────────────────────────────────────┐
│                   Call Stack                          │
│           (synchronous code runs here)               │
│                                                      │
│   console.log("Start")  ← runs immediately           │
│   setTimeout(cb, 2000)  ← registers callback, moves on│
│   console.log("End")    ← runs immediately           │
│                                                      │
└──────────────────────────┬───────────────────────────┘
                           │
              "Is the call stack empty?"
                           │
                    YES ↓  NO → keep running
                           │
┌──────────────────────────┴───────────────────────────┐
│                   Task Queue                          │
│        (async callbacks wait here)                   │
│                                                      │
│   [callback from setTimeout]  ← waiting...           │
│                                                      │
│   When call stack is empty, this moves up ↑           │
└──────────────────────────────────────────────────────┘

The EVENT LOOP continuously checks:
  "Is the call stack empty? If yes, take the next task
   from the queue and put it on the stack."

Step-by-Step Trace

Code: console.log("A");
      setTimeout(() => console.log("B"), 0);
      console.log("C");

Step 1:  Call Stack: [console.log("A")]     → prints "A"
Step 2:  Call Stack: [setTimeout(cb, 0)]    → registers cb, removed
         Task Queue: [cb]
Step 3:  Call Stack: [console.log("C")]     → prints "C"
Step 4:  Call Stack: EMPTY
         Event Loop: "Stack empty? Yes → move cb from queue to stack"
Step 5:  Call Stack: [console.log("B")]     → prints "B"

Output: A, C, B

This is why "B" prints last even with a 0ms delay. The callback always waits for all synchronous code to finish before it can run.

Synchronous vs Asynchronous — Side by Side

Feature	Synchronous	Asynchronous
Execution	One at a time, in order	Start task, move on, handle result later
Blocking?	✅ Yes — waits for each task	❌ No — moves on immediately
UI impact	Can freeze the page	Keeps the page responsive
Use case	Simple calculations, variable assignment	API calls, timers, file reads, user events
Code complexity	Simple, linear	Requires callbacks, promises, or async/await
Example	`let x = 1 + 2;`	`fetch(url).then(...)`

Everyday Analogy

SYNCHRONOUS — doing laundry the blocking way:
  1. Put clothes in washer → WAIT 45 min → done
  2. Move to dryer → WAIT 60 min → done
  3. Fold clothes → done
  Total: You did NOTHING else for 2 hours.

ASYNCHRONOUS — doing laundry the smart way:
  1. Put clothes in washer → go cook dinner
  2. Washer beeps → move to dryer → go read a book
  3. Dryer beeps → fold clothes
  Total: You cooked dinner AND read a book while waiting.

Problems That Occur with Blocking Code

1. Frozen UI

If JavaScript is busy with a synchronous task, the browser can't update the screen, respond to clicks, or animate anything. Users see a frozen, unresponsive page.

2. Poor User Experience

Nobody wants to wait 3 seconds staring at a blank screen while data loads. Async code lets you show loading spinners, skeleton screens, or partial content while data arrives.

3. Timeouts and Failures

Synchronous network requests (which are deprecated for good reason) would freeze the browser until the server responds — or until the request times out, leaving the user stuck.

4. Wasted Resources

A single-threaded language that blocks means the CPU is idle during I/O waits. Async code lets the CPU do useful work while waiting for slow operations to complete.

Let's Practice: Hands-On Assignment

Part 1: Predict the Output

console.log("1");
setTimeout(() => console.log("2"), 1000);
console.log("3");
setTimeout(() => console.log("4"), 0);
console.log("5");

Answer: 1, 3, 5, 4, 2

1, 3, 5 are synchronous — they run immediately in order.
4 has 0ms delay but still waits for synchronous code to finish.
2 has 1000ms delay — runs last.

Part 2: Simulate Async Data Loading

console.log("📡 Fetching user data...");

setTimeout(() => {
  const user = { name: "Pratham", role: "developer" };
  console.log(`✅ User loaded: ${user.name} (${user.role})`);
}, 2000);

console.log("⏳ Meanwhile, showing the rest of the page...");
console.log("📰 News section loaded.");
console.log("📊 Dashboard widgets loaded.");

Output:

📡 Fetching user data...
⏳ Meanwhile, showing the rest of the page...
📰 News section loaded.
📊 Dashboard widgets loaded.
✅ User loaded: Pratham (developer)   ← arrives 2 seconds later

Part 3: Experience Blocking vs Non-Blocking

// ❌ Blocking version — freezes everything for 3 seconds
console.log("Start (blocking)");
const start = Date.now();
while (Date.now() - start < 3000) {} // busy wait
console.log("End (blocking)"); // prints after 3 seconds of freezing

// ✅ Non-blocking version — doesn't freeze anything
console.log("Start (non-blocking)");
setTimeout(() => {
  console.log("End (non-blocking)"); // prints after 3 seconds, but nothing froze
}, 3000);
console.log("Still running other code!"); // prints immediately

Key Takeaways

Synchronous code runs one line at a time, in order. Each line waits for the previous one to finish. Simple but potentially blocking.
Asynchronous code starts a task and moves on. The result is handled later via callbacks, promises, or async/await. Non-blocking.
JavaScript is single-threaded but uses an event loop and task queue to handle async operations without blocking the main thread.
Blocking code freezes the UI, wastes CPU time, and creates terrible user experiences. Async code keeps everything responsive.
setTimeout, fetch, event listeners, and file I/O are all asynchronous — they register callbacks that execute after all synchronous code finishes.

Wrapping Up

Understanding the difference between synchronous and asynchronous JavaScript is one of the most important mental shifts you'll make as a developer. Once you see that JavaScript doesn't "wait" for slow tasks — it moves on and comes back later — a huge amount of confusing behavior starts making sense. The order of console.log outputs, how fetch works, why your data is undefined before the API responds — it all clicks.

I'm working through all of this in the ChaiCode Web Dev Cohort 2026 under Hitesh Chaudhary and Piyush Garg. This article is the foundation — next comes promises, async/await, and the full event loop picture. But understanding sync vs async first makes everything that follows much easier.

Connect with me on LinkedIn or visit PrathamDEV.in. More articles coming as the journey continues.

Happy coding! 🚀

Written by Pratham Bhardwaj | Web Dev Cohort 2026, ChaiCode

Coding Cat Oran S2 Ep1 — The Excel Republic

SysLayer — Sun, 10 May 2026 10:51:45 +0000

A story about trial production, three departments, and three versions of the truth.

It's 7am on the production floor.

Three people are standing around a whiteboard.
One is from QA. One is from Engineering. One is from Manufacturing.
They are arguing about a number.

The number is the yield rate for Product A, Batch 7, last Tuesday.

QA says: 87%.
Engineering says: 91%.
Manufacturing says: "Depends on which shift."

All three are holding laptops.
All three are looking at Excel files.
All three are right.

Oran is an orange cat. No CS degree.
He learned to code at night, online, on his own time,
with AI tools and courses he bought on sale.

He got hired anyway. It's that kind of year.

His job title is IT. His actual job is: whatever nobody else wants to do.

This week, his job is to reconcile the production data.

He sits down. He opens all three Excel files.

The columns have different names.
The formulas have different logic.
The defect definitions are different.
QA counts a scratch as a defect. Manufacturing counts it as cosmetic. Engineering doesn't count it at all unless it affects function.

Same scratch. Three categories. Three numbers.

Oran closes his laptop.
He stares at the ceiling for a long time.

Here is what Oran understands, sitting in that chair:

The data problem is not a data problem.

It's a political problem dressed as a data problem.

Each department's Excel file is their scoreboard.
Their evidence. Their alibi.
If QA's numbers are the official numbers, QA controls the narrative.
If Engineering's numbers are official, Engineering does.
If they merge into one system, someone's score gets worse.

Nobody built these spreadsheets to hide information.
They built them to protect themselves.
That's different. And it's harder to fix.

Oran opens a blank document.

He doesn't start with a database schema.
He doesn't start with a system architecture.
He starts with a question:

What would it mean for all three of these numbers to be correct at the same time?

He writes:

Inspection timing is different. QA measures at end-of-line. Engineering measures at each station. Manufacturing measures at shipment.
Defect scope is different. Three departments, three definitions, never written down anywhere.
The data is collected by different people, at different times, with different tools, for different audiences.

One batch. One production run. Six data points that look like contradictions but are actually just context.

The problem isn't that the data is wrong.
The problem is that there's no single place that holds all of it together.

That evening, Oran writes the first three lines of what will eventually become a database schema.

He doesn't know that yet.
He thinks he's just taking notes.

-- What actually happened
-- Who was there
-- When

He looks at the three Excel files one more time.

Then he writes a fourth line:

-- And what "defect" means in this context

There were three versions of the truth.
Everyone was lying. No one was wrong.
The database didn't exist yet.
But the problem did.

Learning Xahau: Debunking Common Myths About Xahau

Ekiserrepe — Sun, 10 May 2026 10:50:31 +0000

If you spend enough time reading discussions about Xahau, you’ll quickly notice that many people talk about the blockchain and its capabilities without fully understanding how it actually works.

The rise of AI-generated content, combined with the lack of deep technical research in many online discussions, has created an environment where misinformation spreads extremely fast. Over the last few months, I’ve repeatedly seen the same myths, misunderstandings, and inaccurate comparisons appear across social media.

So I decided to write this article to help clarify some of the most common misconceptions surrounding Xahau.

If you want to learn more about Xahau, I also recommend checking out the rest of the Learning Xahau series, where I share information about the ecosystem, automation concepts, development ideas, and practical use cases for builders interested in working with Xahau.

Today, however, we’re going to focus on breaking down some of the most common myths I’ve encountered online.

1. “Xahau Is an XRP Ledger Sidechain”

This is probably the most repeated myth.

XRP Ledger and Xahau share technological origins, but Xahau is not a native sidechain connected to the XRP Ledger.

Xahau is an independent Layer 1 blockchain built from a fork of XRPL code that evolved in a completely different direction.

That means:

Xahau has its own validators
Xahau has its own native asset: XAH
Xahau has its own governance and technical evolution
XRPL amendments do not automatically appear on Xahau

Both networks may occasionally adopt ideas from one another, but they evolve independently.

There are features available on XRP Ledger that do not exist on Xahau, and there are features on Xahau that do not exist on XRP Ledger.

Part of the sidechain confusion comes from the early history of the project.

In the beginning, Xahau was actually described as a sidechain, including in early versions of its whitepaper. At that time, there was a mechanism where XRP could be burned on the XRP Ledger and converted into XAH on the Xahau blockchain. However, that process was eventually closed. Once that bridge mechanism disappeared, the term “sidechain” no longer made technical sense.

Today, Xahau operates as an independent Layer 1 blockchain, even though it still shares part of its original codebase heritage with XRP Ledger.

2. “Projects Built on Xahau Don’t Actually Use XAH”

This is another claim I’ve seen online that honestly surprised me.

In many blockchain ecosystems, “adoption” often refers to companies using private versions of the technology, centralized services, or additional enterprise services offered by blockchain companies, while still presenting it publicly as if they were directly using the public blockchain itself. In some cases, the public chain or its native asset barely participates in the actual operation behind the scenes. Xahau works differently.

To interact with the network, you need XAH. Because XAH is the native asset required for network operation. XAH is a gas token.

XAH is used for:

Account/Object reserves
Transaction execution
Hook interactions

There is no artificial separation between “the technology” and “the public blockchain.” Xahau only makes sense if the blockchain itself is actively used.

3. “Hooks Are Just Ethereum Smart Contracts”

No. While both systems enable automation, the philosophy behind them is completely different.

In Ethereum, smart contracts are typically full decentralized applications deployed directly on-chain. In Xahau, Hooks are lightweight pieces of logic attached directly to accounts that react to specific ledger events.

This creates a very different model:

Compact logic
Deterministic behavior
Native account integration
Direct financial automation

Hooks were never designed to replicate the EVM.

4. “The XAH You See on XRPL Is Native XAH”

No.

When you see XAH traded on the XRP Ledger DEX, you are usually seeing an IOU representation of XAH, not native XAH itself.

Even worse, multiple fake IOUs using the name “XAH” have appeared over time, created by scammers attempting to mislead users.

At the moment, the main legitimate XAH IOU on XRPL is issued by Gatehub:

Currency Code: XAH
Issuer: rswh1fvyLqHizBS2awu1vs6QcmwTBd9qiv

Native XAH only exists directly on the Xahau blockchain. This is similar to how wrapped versions of BTC or ETH exist on other blockchains without being the native assets themselves.

And this distinction matters because certain features only exist directly on Xahau, such as Balance Adjustment, which currently provides around 4%.

5. “Xahau Is Just XRP Ledger With Smart Contracts”

That explanation is far too simplistic.

Yes, Hooks are one of the biggest innovations introduced by Xahau. But Xahau also introduces new programmable dynamics and a different philosophy around financial automation.

The goal is not simply to “add smart contracts.”

The goal is to allow users to integrate custom business logic directly into the ledger itself. That fundamentally changes how financial systems can be automated.

6. “Hooks Are Dangerous Because They Can Do Anything”

Actually, Hooks were specifically designed with limitations in mind. Strict execution limits and deterministic behavior exist precisely to avoid many of the problems seen in more open smart contract environments. Those limitations are not weaknesses. They are part of the design philosophy.

Instead of allowing infinite complexity, Hooks prioritize:

Predictability
Efficiency
Security
Low operational costs
Native integration

7. “Xahau Depends on Ripple”

Ripple does not own or control Xahau.

Xahau emerged after years of research and development surrounding Hooks technology. Originally, Hooks were expected to become part of XRP Ledger itself. However, after significant pushback, the developers behind the Hooks project decided not to abandon years of work and instead launched an independent blockchain where Hooks could exist natively: Xahau.

Like XRPL, Xahau is built using open-source technology and independent validators. Ripple has no governance control or any type of control over Xahau.

Interestingly, it was later announced that a certain level of programmability would be introduced to the XRP Ledger, beginning with features such as Smart Escrows, expected around late 2025. As of May 2026, those features have still not arrived in production.

8. “Xahau Is Trying to Compete With Every Other Blockchain”

The blockchain industry often frames everything as a constant war between ecosystems:

One chain vs another
One token vs another
One community attacking another

But Xahau does not necessarily need to operate under that mentality. Financial institutions are free to use whatever technologies they consider useful. And in reality, most companies rarely depend on a single infrastructure provider.

An organization may simultaneously use:

Multiple blockchains
Traditional banking systems
Private infrastructure
Internal automation tools

Xahau does not need to “win” a blockchain war to be useful.

There’s also an uncomfortable reality within this industry:

Many blockchain companies directly or indirectly pay for institutional pilots and demonstrations through:

PoCs
Pilot programs
Corporate demos
Marketing partnerships

And in many cases, those institutions never end up using the public blockchain or native token at all. Yet the announcements are still heavily promoted to generate speculation and marketing narratives. That creates enormous confusion within crypto communities.

Xahau is attempting to follow a different philosophy. The goal is not to manufacture headlines. The goal is to build tools that can actually function in real regulatory and financial environments. And if institutions choose to combine Xahau with other technologies, they can. Because the objective is not to “win a competition.” The objective is to build useful technology.

Final Thoughts

Understanding Xahau requires looking beyond the usual blockchain narratives. Too often, people try to categorize every project using the same labels: Ethereum competitor, XRPL sidechain, smart contract platform, or DeFi chain. But Xahau was not designed to fit neatly into those categories. Its philosophy is different.

Instead of chasing maximum complexity, Xahau focuses on making financial automation more integrated, predictable, and usable directly at the ledger level.

Whether Xahau succeeds long term will ultimately depend on real adoption, real builders, and real utility, not marketing narratives or social media speculation.

And that is probably the most important thing to understand about Xahau: the goal is not to imitate what already exists, but to explore a different way of building programmable financial systems.

Bootstrapping a Serverless CRM: Surviving a Forensic P0 Audit & Hardening Supabase

Miloš Kulpinski — Sun, 10 May 2026 10:44:17 +0000

Note: I am launching the LuKul Bio-Sync CRM architecture on Product Hunt this Wednesday. If you are a systems architect handling complex biometric telemetry or migrating monoliths to Next.js, I’d love your technical teardown on the launch here.

After 16 years running elite coaching operations in the GCC, I got tired of standard fitness SaaS dropping high-value biometric data. I transitioned to software engineering and built LuKul Bio-Sync—a serverless B2B CRM and PWA ecosystem—entirely from scratch as a solo developer.

To ship the MVP fast, I built it in Vanilla JS, HTML, and CSS, backed by Supabase (PostgreSQL + Edge Functions). The product-market fit was immediate. It retained clients, acquired new ones, and generated revenue.

Then, I ran a full Production-Grade Forensic Systems Audit. The results were terrifying.

The Fragility of the Vanilla Monolith
The audit uncovered a massive gap between the conceptual brilliance of the product (which featured an Ephemeral State Engine and time-decaying somatic heatmaps) and its operational security. I had built a prototype that was operating at a SaaS scale, and the architectural seams were cracking.

My "ship-it-fast" approach had introduced critical vulnerabilities:

Global API Exposure (P1): window.supabaseClient was initialized globally, creating a trivial target for XSS amplification where any injected payload could hijack the authenticated user's RLS permissions.

Orphaned Closures & Memory Leaks: During "Nuclear Wipes" (clearing the DOM via .innerHTML = ""), global event listeners stacked infinitely on the document object, severely degrading performance.

Unauthenticated Edge Webhooks (P1): Mission-critical data pipelines (like somatic_sync) were accepting raw payloads without JWT validation.

The "Hydra" Anomaly: The client was fetching infinite historical logs to deduplicate arrays in the main UI thread, choking the browser's memory.

The Defensive Engineering Sprint (Zero-Downtime)
Transitioning from a founder-led project to an enterprise platform required an immediate pivot to defensive engineering. Before migrating the frontend to Next.js, I had to harden the infrastructure.

Here are the specific architectural remediations deployed to production:

Cryptographic Validation & Threat Mitigation
I purged all hardcoded legacy checks and implemented a timing-safe, constant-time bitwise XOR comparison at the Edge to handle administrative overrides. To neutralize open relay spam vectors, I engineered a pg_cron garbage-collected atomic rate limiter using Postgres RPCs (check_rate_limit), mapping request windows strictly to x-forwarded-for IPs.
RLS Hardening & Singleton Isolation
The global supabaseClient was destroyed. I isolated the SDK payload dynamically via a unified ES6 singleton module, ensuring state could not be read or mutated from the global window scope. Row Level Security (RLS) policies were tightened to strictly enforce is_coach_of() boundaries, preventing vertical privilege bleeding.
Eradicating the "Hydra" (RPC Telemetry)
Client-side array slicing for biometric telemetry was deleted. I pushed the compute burden entirely to the database, invoking strict PostgreSQL RPCs (get_daily_telemetry_batch) with explicit limits to stabilize the render pipeline.

The Next.js 14 & Zustand Architecture
With the backend fortified, the UI is currently undergoing a massive zero-downtime migration to Next.js 14 (App Router) and Zustand.

To maintain 100% visual parity across 5 distinct B2B and consumer locales without rewriting 10,000 lines of legacy CSS, I am leveraging Next.js Route Groups (marketing), (b2b), and (blog-hub). Each layout.tsx imports only its specific legacy CSS dependencies, achieving perfect cascade isolation.

Imperative DOM reads and module-scope variables have been replaced by declarative Zustand stores (e.g., useBotStore for the AI Concierge, useCalculatorStore for in-memory B2B revenue simulations).

The Multimodal Flex: Zero-Dependency Audio Injection
While migrating the heavy infrastructure, I wanted to deploy ElevenLabs AI voice clones across our static editorial pages. Avoiding bloated React audio players, I wrote a lightweight, decoupled Vanilla JS injector. It securely fetches the assets from a public Supabase storage bucket without coupling the .mp3 target to fragile URL paths.

JavaScript

const AUDIO_CONFIG = {
    projectId: 'nwugkqkesolynuzlhqum', 
    bucketName: 'voiceovers',
    containerClass: '.voiceover-container' 
};

class VoiceoverPlayer {
    constructor(container) {
        this.container = container;
        this.slug = this.container.getAttribute('data-slug'); 
        this.audioUrl = `https://${AUDIO_CONFIG.projectId}.supabase.co/storage/v1/object/public/${AUDIO_CONFIG.bucketName}/${this.slug}.mp3`;
        this.audioElement = null;
        this.isPlaying = false;
    }

    async init() {
        if (!this.slug) return;
        if (await this.verifyAudioExists()) {
            this.injectUI();
            this.setupAudio();
        }
    }

    async verifyAudioExists() {
        try {
            return (await fetch(this.audioUrl, { method: 'HEAD' })).ok;
        } catch (error) {
            console.warn(`[LuKul Audio] Fetch failed: ${this.slug}`);
            return false;
        }
    }

    injectUI() {
        const playerHTML = `
            <style>
                .lukul-audio-wrapper {
                    display: inline-flex; align-items: center; background-color: #0a0a0a;
                    border: 1px solid #1a1a1a; padding: 8px 16px; font-family: monospace;
                    cursor: pointer; transition: all 0.3s ease; margin: 20px 0;
                }
                .lukul-audio-wrapper:hover { border-color: #cda434; }
                .lukul-play-icon {
                    width: 0; height: 0; border-top: 6px solid transparent;
                    border-bottom: 6px solid transparent; border-left: 10px solid #2e8b57;
                    margin-right: 12px; transition: all 0.2s ease;
                }
                .lukul-audio-wrapper.playing .lukul-play-icon {
                    border: none; width: 10px; height: 12px; background-color: #cda434;
                    border-left: 3px solid #cda434; border-right: 3px solid #cda434; box-sizing: border-box;
                }
                .lukul-audio-text { color: #e0e0e0; font-size: 0.85rem; text-transform: uppercase; }
            </style>
            <div class="lukul-audio-wrapper">
                <div class="lukul-play-icon"></div>
                <span class="lukul-audio-text">Listen to Architectural Breakdown</span>
            </div>
        `;
        this.container.innerHTML = playerHTML;
    }

    setupAudio() {
        this.audioElement = new Audio(this.audioUrl);
        const btn = this.container.querySelector('.lukul-audio-wrapper');
        const text = btn.querySelector('.lukul-audio-text');

        btn.addEventListener('click', () => {
            if (this.isPlaying) {
                this.audioElement.pause();
                btn.classList.remove('playing');
                text.innerText = 'Listen to Architectural Breakdown';
            } else {
                this.audioElement.play().then(() => {
                    btn.classList.add('playing');
                    text.innerText = 'Playing...';
                    this.isPlaying = true;
                }).catch(e => console.error("Audio blocked:", e));
            }
        });

        this.audioElement.addEventListener('ended', () => {
            this.isPlaying = false;
            btn.classList.remove('playing');
            text.innerText = 'Listen to Architectural Breakdown';
        });
    }
}

document.addEventListener('DOMContentLoaded', () => {
    document.querySelectorAll(AUDIO_CONFIG.containerClass).forEach(c => new VoiceoverPlayer(c).init());
});

If you are dealing with technical debt, securing Edge Functions, or mapping complex relational telemetry in Supabase, let’s connect.

Domain: lukulatelier.com/business

Stack: Next.js 14, Zustand, Supabase, Vanilla JS

Why Your RAG Chatbot Looks Great in Week 1 and Hallucinates by Month 2

Akshay Kumar BM — Sun, 10 May 2026 10:43:34 +0000

💡 Week 1 demo → "this is amazing."

Month 2 production → "why is it hallucinating?"

I've seen this pattern more times than I can count. The team builds a RAG chatbot. It works beautifully on the 20 questions they tested it with. They ship it. Real users show up with real questions. The cracks appear.

The model is almost never the problem.

The system around it is.

After shipping 10+ production RAG systems — handling everything from 100 queries a day to 1,000+ a week at 95% accuracy — I've narrowed it down to four things that consistently separate the ones that keep working from the ones that quietly get abandoned.

Here's what I follow on every build now.

🔍 Why RAG Fails in Production (It's Not the Model)

Most teams build RAG like this:

→ Grab the documents
→ Chunk and embed them
→ Add a retriever
→ Write a prompt
→ Ship it

It works in the demo because the demo is a controlled environment. You know the questions. You've tested on a small, clean set of docs. The model looks smart.

Production breaks this in three ways.

Real users ask questions the team never anticipated. The retriever pulls the wrong chunks. The model doesn't know it retrieved the wrong chunks. It answers anyway.

The knowledge base is messier than it looked. Confluence pages that conflict with each other. Slack threads that reference decisions never written down. Google Docs with five versions. The model retrieves all of it and synthesizes a "confident average" — which is a hallucination with citations.

There's no feedback loop. Nobody knows which answers are wrong until a user complains, by which point the damage is done.

Research confirms this isn't a fringe problem: 40–60% of RAG implementations never make it to production at all. Of the ones that do, naive RAG — embed, retrieve top-k, prompt — consistently plateaus at 70–80% retrieval precision without additional structure around it.

The fix isn't a better model. It's building the system properly.

🧠 Rule 1: Evals Before Prompts

This is the highest-leverage thing I do on every RAG project, and it's the thing most teams skip.

Before writing a single prompt, build a test set of 30–40 real questions with expected answers. Run every prompt change — every chunk size tweak, every retriever adjustment — against the full set.

Without this, you're optimizing blind. You fix one question and break three others without knowing it.

# eval_set.py — structure for a minimal RAG eval set

eval_set = [
    {
        "question": "What is our refund policy for enterprise customers?",
        "expected_answer": "Enterprise customers get a 30-day money-back guarantee.",
        "source_doc": "enterprise-policy-v3.md",
        "category": "policy"
    },
    {
        "question": "Who do I contact for billing issues?",
        "expected_answer": "billing@company.com or the #billing Slack channel.",
        "source_doc": "support-contacts.md",
        "category": "contacts"
    },
    # ... 30-40 total, covering every major topic area
]

def run_eval(rag_chain, eval_set):
    results = []
    for item in eval_set:
        response = rag_chain.invoke(item["question"])
        results.append({
            "question": item["question"],
            "expected": item["expected_answer"],
            "actual": response["answer"],
            "sources_retrieved": response["source_documents"],
        })
    return results

📌 Pro tip: Pull the questions from real user queries where possible. If you have a Slack channel where employees ask the kind of questions the bot will answer, mine it for the first 30 questions. Real questions are always harder than invented ones.

The eval set also tells you when you're done. "Good enough" stops being subjective — either it passes 90%+ of cases or it doesn't ship.

Worth noting: in 2026, 60% of RAG deployments include systematic evaluation from day one, up from under 30% in early 2025. The teams that skipped it are the ones rebuilding their systems now.

🛠 Rule 2: One Source of Truth

Most RAG failures I've traced start here — not in the model.

The knowledge is scattered. Confluence has the official policy. Someone updated it in a Google Doc but didn't update Confluence. There's a Slack thread where a manager made a call that contradicts both. The RAG system indexes all three.

The model retrieves two conflicting chunks. It can't tell which is authoritative. It synthesizes a confident-sounding answer that blends both — and matches neither.

No retriever in the world solves this. It's a data problem, not a model problem.

Step 1 of every RAG project I touch is not building the bot. It's forcing a canonical source:

→ Pick one system as ground truth per knowledge domain (Confluence for policy, Notion for specs, etc.)
→ Archive or redirect any conflicting copies — if it's not in the canonical source, it doesn't exist for the bot
→ Set an update SLA: if a policy changes, the canonical page gets updated within 24 hours

graph TD
    A[User Query] --> B[Retriever]
    B --> C{Single canonical source?}
    C -->|Yes| D[Clean, consistent chunks]
    C -->|No| E[Conflicting chunks from 3 systems]
    D --> F[Faithful, accurate answer]
    E --> G[Confident hallucination]

This sounds like busywork. It's actually the most important infrastructure decision in the project.

Research backs it up: 60% of enterprise RAG projects fail not because of poor retrieval, but because they can't maintain data freshness at scale. One study found that when given unvetted baseline data, models fabricated responses for 52% of out-of-scope questions — not because the model was bad, but because it had no way to know what it didn't know.

🎯 Rule 3: Fallback Over Hallucination

A system that says "I don't know" is more valuable than one that guesses wrong.

This sounds obvious. It's almost never implemented.

The failure mode: the retriever pulls chunks that are loosely related but not actually relevant. The model generates a plausible-sounding answer from them. The user reads it. They have no way to know it's wrong. They act on it.

Trust is built one answer at a time. It's destroyed the same way.

Here's the pattern I use — a confidence-based router that sends uncertain answers to a human instead of letting the model guess:

# confidence_router.py

CONFIDENCE_THRESHOLD = 0.75

def route_with_fallback(query, rag_chain, retriever):
    docs = retriever.get_relevant_documents(query)

    # No docs or low retrieval confidence → route to human
    top_score = docs[0].metadata.get("score", 0) if docs else 0

    if top_score < CONFIDENCE_THRESHOLD or not docs:
        return {
            "answer": (
                "I'm not confident I have accurate information on this. "
                "Let me tag someone who can help — @support-team"
            ),
            "routed_to_human": True,
            "query": query,
        }

    response = rag_chain.invoke(query)
    return {
        "answer": response["answer"],
        "routed_to_human": False,
        "sources": response["source_documents"],
    }

📌 Pro tip: Log every query that gets routed to a human. These are your highest-value training questions. Add them to the eval set with the correct answer documented. Over time, the system learns its own blind spots.

The fallback message matters too. "I don't know — here's who does" is not a failure. Users who get honest fallbacks trust the system more than users who get confidently wrong answers twice.

💡 Rule 4: Observability from Day One

The eval set is your pre-deployment safety net. Observability is your production safety net.

Log every conversation. Not just the query and the answer — log the retrieved chunks, the retrieval scores, the prompt constructed, and the final response.

# logger.py — minimal production RAG logging

import json
from datetime import datetime

def log_rag_event(query, retrieved_docs, response, routed_to_human, metadata={}):
    event = {
        "timestamp": datetime.utcnow().isoformat(),
        "query": query,
        "retrieved_chunks": [
            {
                "content": doc.page_content[:200],
                "score": doc.metadata.get("score"),
                "source": doc.metadata.get("source"),
            }
            for doc in retrieved_docs
        ],
        "response": response,
        "routed_to_human": routed_to_human,
        **metadata,
    }
    # Write to your logging backend — CloudWatch, Datadog, a flat file
    print(json.dumps(event))
    return event

Then build the review loop:

→ Flag every answer that gets a thumbs-down or triggers a human escalation
→ Review flagged answers weekly (30 minutes, not hours)
→ Add wrong answers to the eval set with the correct answer documented
→ Re-run evals before the next deployment

This loop is what makes the system improve over time instead of silently degrade.

The eval set starts at 30–40 questions. Six months in, it's 150 questions covering every edge case real users found. The system that was 80% accurate in week 1 is genuinely 95% accurate by month 6 — not because the model changed, but because the system around it got tighter.

Tools I've used for this: LangSmith for tracing and full conversation logging, RAGAS for automated eval scoring, and a simple shared spreadsheet for the human review loop. You don't need an elaborate stack. You need the habit.

Key Takeaways

✅ Write 30–40 eval questions before a single prompt — this is the line between a demo and a system you can maintain
✅ Fix the data before building the bot — no retriever fixes conflicting or fragmented knowledge sources
✅ A system that says "I don't know" is more valuable than one that confidently hallucinates

The pattern I keep seeing: teams spend time optimizing the part that's already good (the model) and skip the parts that actually break in production (evals, data quality, fallbacks, observability). The boring infrastructure is what makes the intelligent part work.

If you're building or inheriting a RAG system that performs well in testing but keeps surfacing wrong answers in production — these four things are almost always where it breaks.

👋 Let's Connect

If you found this useful or want to talk through a similar problem:

🔗 LinkedIn | 💻 Portfolio | 📧 akshaykumarbedre.bm@gmail.com

I Built Graphode — An AI-Powered GitHub Repository Visualizer

Harsh Kalia — Sun, 10 May 2026 10:39:56 +0000

I Built Graphode — An AI-Powered GitHub Repository Visualizer

Ever spent hours trying to understand a new codebase? I did too. So I built Graphode to solve that problem.

What is Graphode?

An AI-powered GitHub repository visualizer that helps you understand any codebase in minutes, not hours.

Just upload a GitHub repo → Get instant insights on architecture, dependencies & code flow → Understand what you're looking at.

Watch it in action:

Features

✓ AI-Powered Analysis — Uses Google Gemini AI to analyze your code
✓ Visual Architecture — See dependencies & code flow instantly
✓ Real-Time Collaboration — Analyze together with your team
✓ Instant Insights — No more hours wasted on code exploration

Perfect For

Code reviews
Onboarding new team members
Diving into unfamiliar projects
Understanding legacy codebases

Try it free

https://graphode.tech/

Would love your feedback! Let me know what you think in the comments 🙌

Building Echovault During a 130,000 Person Hackathon

Ugo Nwune — Sun, 10 May 2026 10:37:09 +0000

A few months ago I entered the world’s largest hackathon with over 130,000 competitors.

My original project idea had nothing to do with AI memory preservation.

I started by building a social commerce platform called OAK where people could upload clothing designs and have them printed onto real garments and shipped. Halfway through the competition I realized I wasn’t emotionally connected to the idea, and honestly it didn’t feel differentiated enough to compete at that scale.

One of the hackathon sponsors was Tavus.

Around that time I remembered a voice note my uncle sent me before he was killed in Nigeria.

For years I replayed that recording during difficult periods of my life. Hearing his voice still carried emotional weight long after he was gone. But eventually I kept thinking about something unsettling:

the voice note was static.

I could replay it forever, but I could never ask a new question.
I could never hear a new story.
The memory was frozen in time.

That realization became the foundation for Echovault.

I pivoted completely and spent the next 9 days building an AI digital legacy platform designed to preserve a person’s memories, personality, stories, and voice for future generations.

The Stack

The project started on Bolt.new since the hackathon required it, then eventually moved into Cursor for faster iteration.

The stack ended up looking like this:

React frontend
Supabase backend
Gemini for NLP and embeddings
Tavus for conversational video
ElevenLabs for voice synthesis

Mostly written in typescript and deployed on vercel. The core idea behind Echovault was building an “Echo,” an AI representation of a person trained on their memories, personality traits, and life experiences through guided conversations.

The Disaster Moment

At one point during development, an AI assistant accidentally triggered a database reset during a prompt chain.

I blindly approved it.

The entire database disappeared instantly.

That mistake cost nearly two full days of recovery work. I had to rebuild from an old schema.sql file inside the workspace, recreate missing tables manually, and rewrite parts of the RLS policies to secure the database properly again.

The recovered database was never quite the same afterward, but the project survived.

The Result

Echovault ended up winning the “Most Inspirational Story” award at the hackathon.

Part of me secretly hoped to win something more technical because I was proud of how ambitious the architecture became under such a short timeline, but the award still meant a lot because the story behind the product was deeply personal.

The experience completely changed how I think about software creation.

Long term, my goal is to make Echovault a legitimate way for people to digitally preserve themselves for the far future.

https://echovault.me