Mert

The two a.m. pager call is a rite of passage for many engineers, but the nature of those incidents is starting to change.

Picture this. You just finished reviewing a pull request that looked almost perfect. The logic was clean, the variable names were descriptive and the code even included comments explaining what each section was doing. The CI pipeline passed without a single failure, so you merged it with confidence and moved on to the next task.

A few hours later the alerts begin.

The service starts timing out, and requests begin to pile up faster than the system can handle. When the team traces the issue back to the code that shipped earlier, the problem turns out to be surprisingly subtle. The AI-generated function that looked so polished during review assumed the database would always have connections available. In staging that assumption held. In production, where thousands of requests arrive at the same time, the same logic quickly exhausts the connection pool.

This is the new reality of AI-assisted development. Teams are moving faster than ever, generating large portions of working code in minutes rather than hours. At the same time, they are encountering a different class of bugs. These issues look perfectly reasonable in isolation but behave very differently once they interact with real production environments.

This article explores why AI-generated code requires a different approach to review and introduces a practical checklist that engineering teams can use to catch the patterns these systems consistently introduce before the code reaches production.

TL;DR: AI Code Review Cheat Sheet

If you only have a few minutes to review an AI-generated pull request, focus on these five areas.

Why AI Code Needs a Different Review

Most teams have already integrated AI into their daily workflow. Tools like GitHub Copilot or Claude now act as high-speed pair programmers that never get tired. They can scaffold functions, generate tests and fill in repetitive implementation details in seconds. This speed is a real productivity boost, but it also introduces a trade-off that many teams are only beginning to see.

Recent analyses suggest that AI-generated code can have significantly higher defect rates compared to human-written code. Some studies report roughly 1.7 times more defects overall, including about 75 percent more logic issues and nearly twice the number of security vulnerabilities. The surprising part is that many of these problems are not obvious during code review because the implementation often looks correct at first glance.

The root of the issue is a gap in context. When human developers write code, they bring a mental model of the system they are working inside. They know which services behave unpredictably, which APIs struggle under load and which operational constraints shape how the system behaves in production.

AI models do not have that history. They generate code that follows common patterns but cannot account for the specific environment where the code will run. Because of this, the mistakes produced by AI tend to look different from the ones engineers usually introduce. Human errors often come from oversight or incomplete reasoning. AI errors tend to come from missing assumptions. The generated code handles the main path well, but quietly skips the conditions that only appear under real workloads or unusual inputs.

That difference means AI-generated pull requests require a slightly different review mindset. Instead of asking only whether the implementation works, reviewers need to consider where hidden assumptions might break once the code interacts with real data, real traffic and real infrastructure.

Category 1: Logic and Correctness

The most common logical trap in AI-generated code is what many reviewers describe as a “happy path” obsession. The model assumes the data exists, the API responds correctly and the user follows the expected flow. The result is code that looks clean and complete but becomes fragile once real-world conditions begin to deviate from those assumptions. During review, the goal is not only to understand what the code does, but also to identify what it fails to do when something goes wrong.

1. Missing Edge Case Handling

One of the first things to examine is how the code handles edge cases. If a function accepts an array, check for the condition where the array is empty. If the function expects a number, consider how it behaves when the value is zero or negative. Inputs such as null values, empty strings or unusually large datasets are often overlooked because the model focuses on the most common example it was prompted to generate. This creates code that works perfectly in controlled tests but fails in production when an input falls outside the expected range.

2. Weak or Ineffective Error Recovery

Error handling in AI-generated code often appears present but incomplete. Reviewers frequently encounter try-catch blocks where the catch section logs a generic message or performs no meaningful recovery. If a database query fails or a file operation returns an error, the program may simply continue running without resolving the underlying problem. By the time the problem surfaces elsewhere in the system, the original cause may be difficult to trace.

3. Approximate Business Logic

AI models can infer patterns from examples, but they rarely understand the exact business rules a system must enforce. As a result, the generated code may implement something that looks reasonable while quietly skipping an important constraint.

4. Unsafe Control Flow

Another pattern reviewers occasionally encounter involves unsafe control flow. AI-generated code can introduce loops that never terminate, recursion that lacks a clear stopping condition or conditional statements that always evaluate to true. Because the structure of the code looks correct, these issues are easy to overlook during review. In production, however, they can create runaway processes or stalled services.

Category 2: Security

Security is another area where AI-generated code can introduce subtle risks. Language models generate code by reproducing patterns they have seen during training. They do not evaluate whether those patterns represent secure practices or simply common ones. Because insecure examples appear frequently in public repositories, models can reproduce them with the same confidence as secure implementations.

1. Input Handling and Injection

AI-generated code often constructs database queries, file paths or command strings using direct string concatenation. This pattern is common in tutorials and examples, so models frequently reproduce it. During review, pay close attention to any place where user input interacts with a database query, a system command or a file path. If the implementation does not use parameterized queries, input validation or proper binding mechanisms, the code may expose the system to SQL injection, command injection or path traversal vulnerabilities.

2. Authentication and Authorization Gaps

Another recurring issue appears in access control logic. AI-generated code may verify that a user is authenticated but fail to check whether that user is authorized to perform a specific action. For example, an endpoint might confirm that a session is valid before allowing an operation such as deleting an account or modifying a resource. However, the implementation may omit the permission check that ensures the user is actually allowed to perform that action.

3. Sensitive Data Exposure

AI-generated code may also expose sensitive information through logs, configuration values or error messages. Passwords, API tokens, local file paths or personal data sometimes appear in logs because the model attempts to make debugging easier.

In production environments, these habits can create serious risks. During review, verify that secrets are stored in environment variables or secure configuration systems and confirm that sensitive information never appears in logs or error responses.

4. Dependency and Supply Chain Risks

Another pattern reviewers encounter involves external dependencies. AI-generated code may reference outdated libraries, insecure package versions or even hallucinated dependencies.

Because these suggestions often resemble legitimate packages, they can slip past quick reviews. In the worst case, a hallucinated dependency name could be registered by an attacker in a public package registry, creating a potential supply chain attack. Reviewers should always verify that suggested dependencies are necessary, up to date and sourced from trusted repositories.

Category 3: Performance

AI-generated code is typically optimized for correctness and readability rather than performance at scale. In a local development environment with a small dataset, the implementation may run perfectly. Once the same logic operates on millions of records or handles thousands of concurrent requests, the underlying inefficiencies become much more visible.

1. Algorithmic Inefficiency

AI-generated code often relies on simple patterns such as nested loops because they are easy to express and commonly appear in examples. However, when those loops operate on large datasets, the cost grows rapidly.

A nested loop over a large collection can quickly turn a basic operation into an O(n²) performance problem. During review, look for logic that iterates over a list inside another loop or repeatedly scans the same dataset. In many cases, these operations can be replaced with indexed lookups, hash maps or more efficient data structures.

2. Inefficient Database Access

Database interactions are another frequent source of performance problems. AI-generated code may retrieve a list of records and then perform a separate database query for each item in that list. This pattern is commonly known as the N+1 query problem. While the code functions correctly, it can produce hundreds or thousands of database calls in a single request. A better approach is often to use joins, batch queries or preloading strategies that retrieve the required data in fewer database operations.

3. Missing Caching

Another pattern reviewers frequently encounter is repeated computation. AI-generated code may perform the same expensive calculation or external API request every time a function runs, even when the result rarely changes.

Without a caching strategy, this behavior can significantly increase both latency and infrastructure costs. During review, look for opportunities to cache repeated results or memoize operations that produce identical outputs for the same inputs.

4. Resource Management Issues

AI-generated implementations sometimes open resources without properly managing their lifecycle. Database connections, file handles or network sockets may be created without ensuring they are released once the operation completes.

Under light workloads this may not cause immediate problems. Over time, however, these leaked resources accumulate until the service reaches connection limits or exhausts available memory. Reviewers should verify that the implementation uses appropriate cleanup patterns such as context managers, finally blocks or connection pooling.

Category 4: Maintainability

AI-generated code is often easy to read on a first pass. Functions are neatly structured, comments appear helpful and the implementation usually follows familiar patterns. The challenge appears later, when teams begin maintaining or extending that code.

Because language models generate solutions without awareness of the full repository, the resulting code can be duplicated, disconnected from existing utilities or unnecessarily complex. If these patterns are not caught during review, the initial speed gains from AI-generated code can gradually turn into long-term technical debt.

1. Logic Duplication

One of the most common problems is duplicated functionality. AI does not search your codebase for existing utilities before generating a solution. As a result, it may recreate functionality that already exists elsewhere in the system.

You might see a new date-formatting helper, validation function or currency conversion utility even though a standard implementation already exists in the project. Every duplicate function becomes another place where bugs can appear and another piece of logic that must be maintained.

2. Dead Code and Unused Abstractions

AI-generated implementations sometimes include extra components intended to make the solution appear complete. These may include unused helper functions, empty interfaces or abstractions that do not support any real requirement.

While these additions may seem harmless, they increase the complexity of the codebase and make pull requests harder to review. Reviewers should verify that every function, interface or abstraction introduced by the AI is actually used.

3. Generic Naming

Naming is another frequent issue. AI-generated code often relies on vague identifiers such as data, result, handler or obj. While these names are technically valid, they rarely convey meaningful context within a large application. Reviewers should ensure that variables and functions reflect the domain or operation they represent.

4. Redundant Commenting

AI-generated code often contains many comments, but they do not always add useful information. Models frequently produce comments that simply restate what the code already shows.

For example, a comment such as // increment the counter by one placed directly above counter++ adds little value. Useful comments explain why the code exists or what constraint it addresses, rather than describing obvious behavior.

Category 5: Production Readiness

Production readiness is where AI-generated code is most consistently incomplete. This is not because language models are incapable of generating logging or monitoring logic. The issue is that these operational requirements are rarely included in the original prompt. As a result, the model focuses on the feature itself while ignoring the infrastructure that allows engineers to observe and manage that feature in production.

1. Structured Logging

One of the most common gaps in AI-generated code is logging. The core logic may be implemented correctly, but important events such as validation failures, retries or state changes are never recorded.

Reviewers should ensure that critical operations include structured logs with enough metadata to make debugging possible. If a request reaches an important branch or fails validation, the system should record that event in the logging infrastructure so the on-call engineer can understand what happened.

2. Actionable Error Messages

Another frequent issue is vague error reporting. AI-generated code often returns messages such as “Something went wrong,” which provide little insight into the underlying problem. Effective error handling should produce messages that help engineers diagnose failures internally while ensuring that user-facing responses remain safe and do not expose sensitive system details.

3. Monitoring and Trace Hooks

Observability is another area where AI-generated code often falls short. New services, background jobs or heavy processing loops should expose metrics and tracing hooks that allow engineers to monitor performance.

Without these signals, teams may not notice that a new feature is degrading system performance or violating service-level objectives until the issue becomes visible to users.

4. Configuration Management

Configuration handling is another frequent oversight. AI-generated code often hardcodes values such as API endpoints, database connections, file paths or timeout settings directly into the implementation.

While these placeholders may work during testing, they create problems during deployment. Reviewers should confirm that environment-specific values are loaded from configuration systems or environment variables rather than embedded directly in the code.

How to Actually Use This in Your Review Workflow

One useful way to approach AI-generated code reviews is to treat the process like a funnel. Each pass acts as a filter that the code must clear before it earns more of your time. This prevents reviewers from spending fifteen minutes debating naming conventions on a function that is fundamentally broken at the logic level.

The Four-Pass Framework

Logic Pass (5–10 minutes)

Start by verifying the core behavior of the code. Does the implementation actually solve the problem it was meant to address? This is where reviewers check edge cases, error handling and the “happy path” traps discussed earlier. If the code fails on null inputs or breaks with empty arrays, it should be returned for revision before any deeper review.

Security Pass (10–15 minutes)

Once the logic appears sound, shift attention to security. Look for injection risks, permission gaps and places where sensitive data might be exposed. Because automated tools often miss contextual security flaws, this stage is where manual review provides the most value.

Performance and Maintainability Pass (5–10 minutes)

After the code is functional and safe, reviewers can evaluate efficiency and long-term maintainability. Look for nested loops that may create scaling problems, N+1 database queries or repeated logic that already exists elsewhere in the codebase. This is also the right time to check naming clarity and overall architectural consistency.

Production Readiness Pass (5 minutes)

The final pass focuses on operational details. Confirm that logging is present, configuration values are not hardcoded and the code includes the telemetry needed to monitor its behavior in production. This quick scan ensures the system can actually be supported once the feature goes live.

Teams adopting AI-assisted development often discover that reviewing AI-generated code takes slightly longer than reviewing traditional pull requests. In practice, this usually adds 20 to 30 percent more time to the review process.

This happens because the effort shifts from writing code to validating it. When developers write code manually, they usually follow established patterns and can explain the reasoning behind their choices. AI-generated code requires reviewers to confirm that each part of the implementation aligns with the system’s real constraints.

Even with this additional review time, the overall development cycle often becomes faster. The model handles the repetitive scaffolding work, while engineers concentrate on validating the correctness and safety of the final implementation.

Before and After: What a Good AI Code Review Looks Like

Imagine you are in the middle of a sprint and need a quick helper function to pull user profiles from an internal microservice. You prompt your AI assistant to write a Node.js function that fetches data from an API and formats the result. Seconds later, you receive a snippet that looks clean, uses modern syntax and appears ready for a pull request.

async function getUserData(userId) {
  const response = await fetch(`https://api.internal.service/users/${userId}`);
  const data = await response.json();

  const formatted = data.map(user => {
    return {
      id: user.id,
      name: user.name.toUpperCase(),
      email: user.email
    }
  });

  return formatted;
}

At first glance, the implementation looks correct. It performs the API call and maps the result into a clean data structure. If you are working under time pressure, it might be tempting to merge this quickly after a basic test.

However, applying the review checklist reveals several issues that could cause problems in production.

Issues Identified During Review

Logic and correctness: The function assumes that the API request always succeeds. If the service returns a 404 or 500 error, the code will attempt to parse an invalid response with .json(). It also assumes the returned data is always an array. If the API returns null or a single object, the map call will throw an exception.

Security: The userId value is injected directly into the URL string. Even in internal systems, this pattern can introduce risks such as path traversal or unintended API access.

Performance: The request has no timeout protection. If the internal service becomes slow or unresponsive, the function could wait indefinitely and eventually consume available connections. There is also no caching strategy, meaning every call triggers a network request.

Production readiness: The function includes no logging or telemetry. If the request fails or returns unexpected data, engineers will have little information to diagnose the problem.

The Revised Version

After applying the review framework, the function becomes more resilient.

async function getUserData(userId) {
  if (!userId || typeof userId !== 'string') {
    throw new Error('Invalid user ID provided');
  }

  try {
    const controller = new AbortController();
    const timeout = setTimeout(() => controller.abort(), 5000);

    const response = await fetch(
      `https://api.internal.service/users/${encodeURIComponent(userId)}`,
      { signal: controller.signal }
    );

    clearTimeout(timeout);

    if (!response.ok) {
      logger.error('Failed to fetch user data', { userId, status: response.status });
      return [];
    }

    const data = await response.json();

    if (!Array.isArray(data)) {
      logger.warn('Unexpected API response format', { userId });
      return [];
    }

    return data.map(user => ({
      id: user.id,
      name: (user.name || 'Unknown').toUpperCase(),
      email: user.email || 'N/A'
    }));

  } catch (error) {
    logger.error('User data fetch operation failed', { error: error.message, userId });
    return [];
  }
}

The revised implementation introduces input validation, safer URL handling, timeout protection, structured logging and defensive checks for unexpected API responses. None of these changes dramatically alter the logic of the function, but they significantly improve its resilience in real production environments.

Without these safeguards, the original version could easily trigger outages or difficult debugging sessions. A slow upstream service might cause the API to hang indefinitely, and the lack of logging would make the root cause difficult to trace.

This example illustrates the purpose of a structured AI code review. The generated code often looks correct and passes basic tests, but careful review reveals assumptions that only become visible under real operating conditions. A systematic checklist helps teams catch those issues before they reach production.

Wrapping Up

AI-assisted development is accelerating the pace of software engineering. Features that once required hours of manual coding can now be generated in minutes with the help of modern code assistants. That speed is valuable, but it shifts where the real engineering work happens. Instead of spending most of their time writing code, teams increasingly spend their effort validating whether generated implementations actually hold up under real system constraints.

The key insight is that AI-generated code rarely fails because of syntax or obvious mistakes. It fails because of hidden assumptions. A function may work perfectly in isolation while overlooking edge cases, security boundaries, performance limits or operational requirements.

That is why reviewing AI code requires a structured approach. A checklist that covers logic, security, performance, maintainability and production readiness helps reviewers systematically uncover the patterns these systems tend to introduce.

At Bit Cloud, this kind of structured validation is a core part of how forward-deployed engineering teams help organizations move from working prototypes to reliable production systems. When AI can generate code in seconds, disciplined review becomes the safeguard that keeps speed from turning into instability. Teams that combine rapid generation with careful validation are the ones that capture the productivity benefits of AI while maintaining the reliability their systems depend on.

Typical web and mobile development often starts with a few familiar questions:

• What’s the data model going to look like?
• How am I going to handle user accounts and auth?
• Where am I going to host this thing?

Web3 development has its own set of “how do I start?” questions but they’re not the same as what you’d expect if you’re coming from a Web2 background.

Arc 1 of 100 Days of Solana was all about learning those fundamentals.

What are the Solana equivalents of user accounts, dev/prod environments, data storage, and so on?

Identity starts with a keypair

Identify works differently in the Web3 world. It starts with a keypair, rather than an account someone creates for you.

But the similarities with typical user accounts break down once you look at the detail.

A Solana keypair is created on your own computer.

There is no signup request, no account creation API, and no backend service issuing you an identity. Your machine generates two linked pieces of data:

• a public key
• a private key

The public key is your Solana address. You can share it freely, paste it into a faucet, or look it up in a block explorer.

The private key proves that you control that address. You keep it secret, just like you would keep an SSH private key secret.

The important thing to understand is this:

Creating a keypair gives you a valid Solana address, but it does not automatically create anything on-chain.

That can feel strange if you are coming from Web2. In a normal web app, a user account usually appears only after a row is inserted into a database. On Solana, the address can exist before the network has stored any data for it.

So there are two related ideas:

The address:
This exists as soon as your keypair exists. It is just derived from your public key.

The on-chain account:
This exists on a specific Solana cluster only once the network starts storing state for that address. For example, that might happen when you receive devnet SOL from a faucet.

That means a brand-new address can be completely valid, even if Solana Explorer shows no account data for it yet.

It is a bit like generating an SSH key. You can create the key locally before any server knows about it. The public key is real immediately, but it only becomes useful on a specific server once that server has been told about it. On Solana, your address is real immediately, but a particular cluster only stores account state for it once something happens there.

This is one of the first places where the usual Web2 mental model starts to shift. In a Web2 app, an account usually begins as something a service creates and stores. On Solana, control is cryptographic: you control the wallet because you hold the key that can sign for it. No company needs to store your credentials before the address exists, and no admin panel can recover the private key for you.

That is not the whole story of Solana, but it is one of the foundations everything else builds on. If you do not understand what controls an address, transactions, accounts, tokens, and programs all feel more mysterious than they need to.

From generated key to funded address

If you know one thing about Web3, it might be that each blockchain has its own currency. On Solana, that currency is SOL.

SOL is what pays for activity on the network. In Arc 1, though, we did not start by spending real money. We started with devnet SOL: free test tokens used on Solana’s developer network.

A few lines of @solana/kit produced a brand-new keypair. The important call was small: generateKeyPairSigner() created a signer and returned an address that we could print straight to the terminal.

That first step is intentionally plain. Before there is a wallet app, login screen, dashboard, or account setup flow, there is just a keypair:

a public key, which gives you a Solana address
a private key, which proves you control that address

We then funded that address with free devnet SOL from the Solana faucet. More precisely, the faucet sent lamports to the address. Lamports are the smallest unit of SOL, a bit like cents are to dollars, except 1 SOL equals 1,000,000,000 lamports.

After that, a balance check showed that the address now had account state on devnet.

That is a useful break from the usual Web2 sequence.

In a typical web app, the user account usually starts as a row in a database. The app creates the account, stores the user record, and then the user can do things.

On Solana, the address can exist first. It is valid as soon as the keypair is generated. The network only starts storing account state for that address on a particular cluster once something happens there, such as receiving lamports.

Arc 1 also introduced devnet, one of the most important environments for learning Solana. We were not using local mocks or screenshots of a production system. We were using a real Solana cluster with the same core APIs and concepts as mainnet, but with tokens that have no real-world value.

Persistence makes the key useful

Generating a keypair is only the first step.

If the keypair lives only in memory, it disappears when the script exits. That is fine for a quick demo, but it is not enough if we want to keep using the same Solana identity.

So the next step was persistence. We saved the keypair to a local JSON file, then loaded it again each time the script ran.

That gave us the same address across multiple runs.

This is the point where Solana identity starts to feel less abstract. In a Web2 app, your identity is usually tied to something recoverable: an email address, a password reset flow, maybe a login provider.

With a keypair, the private key is the thing that matters.

If someone has the private key, they can sign transactions for that address. They do not need your password. They do not need your email account. They do not need approval from a backend service.

For devnet, storing a keypair in a local JSON file is fine. There is no real value at stake. But the same approach would be a serious mistake for mainnet funds or production users.

Arc 1 made that visible early:

• Key storage affects security.
• Address reuse affects privacy.
• Signing is how authorization works.

Lamports make value precise

Arc 1 also introduced the unit Solana programs actually work with: lamports.

Wallets usually show balances in SOL because that is easier for humans to read. But Solana code works in lamports because programs need exact whole-number values.

One SOL is 1,000,000,000 lamports.

This should feel familiar if you have worked with payments APIs. Stripe does not ask you to send $19.99 as a decimal amount. It asks for 1999 cents, because money should not be handled with floating point arithmetic.

Solana follows the same basic idea. The network needs every validator to calculate the same result exactly. That means balances, transfers, and fees are represented as integers, not rounded decimal values.

So there are two units to keep straight:

• SOL is the readable display unit.
• Lamports are the exact unit used by the network.

That small distinction teaches a bigger Solana lesson. What humans see is not always what programs store, sign, or verify. As a developer, you need to know when you are dealing with a friendly display value and when you are dealing with the precise value the network will actually use.

The app gets an address, not your private key

After working with raw keypairs in scripts, we connected a real browser wallet.

Using the Wallet Standard and @wallet-standard/app, we built a browser app that could detect installed wallets such as Phantom, Solflare, and Backpack. The app requested a connection, then displayed the selected address and its devnet balance.

That is the important distinction: the app could show the address and read the balance, but it never handled the private key.

The wallet kept custody of the key. The app only received the public address.

For Web2 developers, this is closer to using an external identity provider than asking users to type their password into every app. The app delegates key management to the wallet. When it needs proof that the user controls an address, it asks the wallet to sign something.

But connecting a wallet is not the same as a full login session.

A wallet connection gives the app an address. It tells the app, “This is the address the user has chosen to share.” It does not automatically prove that the user should stay logged in, access a private account, or perform sensitive actions.

For that, an app usually needs a separate signing step. The wallet signs a message or transaction, and that signature proves control of the address. The wallet should ask the user before signing anything meaningful.

That is why real Solana apps should not ask users to paste secret keys into a form. The private key stays in the wallet. The app asks the wallet for addresses and signatures.

Arc 1 covered both raw keypair management and browser wallet connection because they teach different parts of the same model:

Raw keypairs show what is happening underneath.
Wallet connections show how users should normally interact with apps.

If you come from Web2, connecting a wallet can look a bit like “Sign in with Google.”

Your app does not handle the user’s Google password. The user approves access through Google, and your app receives enough information to recognize them.

A Solana wallet plays a similar role in the app experience. It holds the user’s keys, asks for approval, and gives the app a public address to work with.

But the comparison only gets you so far.

Google is an identity provider. It can reset access, suspend accounts, enforce policies, and sit between the user and the apps they use.

A non-custodial wallet is different. It manages keys and asks the user to approve signatures, but it cannot recreate a lost private key. It also cannot invalidate a private key that still exists somewhere else.

That changes the shape of identity.

In a typical Web2 app, identity often starts with a database row. The app creates a user account, stores profile data, and provides recovery flows if something goes wrong.

On Solana, the address is the durable identifier. A signature is the proof that someone controls that address.

Your app can associate data with an address, but it does not own the user’s identity.

That can feel like losing control if you are used to backend-owned accounts. But it is one of the tradeoffs Solana asks developers to understand. Users can bring the same address to different Solana apps. They can connect, approve, disconnect, and move on.

That portability is powerful, but it has a privacy cost. If someone reuses the same address across many apps, their activity may be easier to link together.

That is why the Web2 analogies in Arc 1 are useful, but only up to a point:

• SSH keys help explain keypairs.
• Payments APIs help explain lamports.
• OAuth-style login helps explain wallet connection.

None of those comparisons maps perfectly. But each gives Web2 developers a foothold before the Solana model starts to feel natural.

There is no ordinary password reset

Arc 1 also introduced one of the harder parts of the Solana mental model:

If you lose the private key, there is no ordinary password reset.

In a typical Web2 app, the service controls the account system. That is why it can offer recovery flows. You can reset a password, verify an email address, contact support, or use an identity provider to get back in.

That convenience comes with a tradeoff. The same service can also lock you out, leak credential data, change the rules, or shut the account down.

Solana works differently.

On Solana, control comes from signing. If you can sign with the private key for an address, you control that address. If you cannot sign, the network does not know that you are “really” the owner.

That makes key storage a real product decision, not just a technical detail.

Different approaches make different tradeoffs:

• Browser wallets are convenient, but connected to everyday devices.
• Hardware wallets add protection, but introduce more friction.
• Custodial services can offer recovery, but someone else holds or manages the keys.
• Multisig tools can share control across multiple people or devices.
• Cold storage can improve security, but is less practical for frequent use.

The rule for real apps is simple:

Do not ask users to paste secret keys or seed phrases into your app.

A Solana app should connect to a wallet and ask for signatures. The wallet keeps the private key. The user approves or rejects the request. The app receives only what it needs.

Recovery also has to be designed deliberately. It is not a default support flow you get for free. Seed phrases, hardware wallets, multisig setups, and custody providers all exist because key loss, key theft, and shared control are real product problems.

Once that clicks, self-custody stops sounding like a slogan. It becomes a set of design choices about security, usability, and recovery.

You are building around a different foundation: control is proven by signatures, not granted by a service.

What Arc 1 sets up

By the end of Arc 1, we had worked through the core Solana fundamentals that everything else builds on:

• generating a keypair in code
• understanding public keys and private keys
• funding an address on devnet
• seeing the difference between an address and account state
• saving and reloading a keypair from a local file
• converting between SOL and lamports
• reading raw lamport balances in logs
• connecting a browser wallet to a web app
  • understanding that connecting a wallet and signing are separate actions
• explaining Solana identity in our own words

For Web2 developers, some of this should feel familiar.

If you have generated an SSH key, you already have a starting point for understanding keypairs. If you have used “Sign in with Google,” you already have a rough analogy for wallet connection. If you have handled money in cents through a payments API, you already understand why Solana uses lamports instead of decimal SOL values in code.

None of those comparisons is perfect. But they give us useful footholds.

Want to see the full thing? Check out the 100 Days of Solana daily challenge series.

Wearable technology was originally sold as a simple idea: better data leads to better decisions. These help in tracking your steps, monitoring your sleep, measuring your heart rate and understanding your body better.
But something quietly changed along the way. Today, wearables no longer just collect information, they also interpret it. Your smartwatch doesn’t simply tell you how long you slept, it tells you whether your sleep was good enough. Also, your fitness band doesn’t just measure recovery, it advises whether you should train, rest or slow down.

A 2022 study for The Impact of Wearable Technologies in Health Research found that wearable feedback can significantly influence health behavior and decision-making, especially when data is presented through personalized recommendations rather than raw metrics.

That shift matters more than most people realize. Because wearables were supposed to help humans make decisions. Instead, they’re slowly becoming the decision itself.

The result is subtle but powerful, as devices now influence how people interpret energy, stress, productivity, recovery and even emotions, often before the person has fully processed those feelings.

When Data Stops Informing and Starts Directing

In the early 2010s, wearables were glorified pedometers. They were passive dashboards that told you how many steps you took or what your heart rate was during a sprint. They provided raw data and you, the human, interpreted it.

Today, the relationship is inverted. Modern wearables like the Oura Ring, WHOOP or Apple Watch don’t just give you numbers, they give you interpretations. They tell you how “ready” you are for the day or how much “strain” you can handle.

We are witnessing a transition from Informative UX to Predictive Direction. Humans naturally succumb to the “authority bias”, a tendency to trust a seemingly objective source over our own subjective experience. A study also explored how “nocebo” effects occur with wearables: when users were told they had poor sleep (even if they hadn’t), their cognitive performance actually dropped. We aren’t just reading a screen, we are subconsciously aligning our physical capabilities with an algorithm’s verdict.

For me as a tech enthusiast, this is an advanced lesson on behavior modification. By using color-coded rings and Readiness Scores, apps create a psychological safety net. It’s easier to follow a green icon than it is to listen to the messy, often contradictory signals of our own nervous systems.

The Rise of Algorithmic Intuition

“I’ll see how I feel” has been replaced by “I’ll see what my data says.” We are outsourcing our self-awareness to software. This is what psychologists call Bio-Loop Dependency.

We now look for algorithmic validation for almost every basic human instinct:

• Eating: We check “active calories burned” before deciding if we “earned” a dessert.

• Productivity: We look at our sleep score to decide if today is a “deep work” day or a “slow” day.

• Emotions: We receive a “high stress” alert and suddenly feel the need to be anxious, even if we were just excited about a meeting.

The psychological comfort of external certainty is addictive. Numbers feel objective and scientific, whereas human biology is messy and ambiguous. However, a study by Jordan Etkin found that tracking an activity can actually decrease interest in the activity itself because it turns a hobby into “work.” When we wait for a watch to validate our exhaustion, we lose the ability to sense it ourselves.

Your Body Has Become a Notification System

The irony of modern wearable tech is that it was designed to help us reconnect with our health. In reality, it often creates a digital barrier between our consciousness and our biology.

Before the Apple Watch or the Oura Ring or other wearables, hunger, fatigue and stress were internal sensations that bubbled up from within. Now, those sensations are mediated by vibration alerts and Stand Reminders. The body has effectively become another app on your phone, constantly generating notifications that demand your attention, resulting in a nocebo effect.

When a wearable incorrectly detects a high heart rate while someone is resting, the reaction itself can create anxiety, causing the person’s heart rate to genuinely rise. In that moment, the system is not just detecting a condition, it may also be influencing it. This is where Human-Computer Interaction (HCI) ethics becomes especially important. When a device stays attached to someone nearly 24/7, every design choice, from a red warning indicator to a subtle vibration alert, can directly affect a person’s emotions, attention and physiological response.
The Gamification of Everyday Life
Wearables have successfully turned the act of existing into a game. Streaks, badges and closing rings exploit the most primitive parts of our brain, specifically the dopamine-driven reward system and Loss Aversion.

According to behavioral economics, the pain of losing a 100-day “step streak” is often greater than the joy of actually being healthy. This leads to “Metric Fixation,” where the score becomes more important than the goal it represents.

• People (including me) will walk circles in their living room at 11:45 PM just to “close a ring” before the day ends.

• Athletes will push through genuine injury because their “strain coach” hasn’t peaked yet.

In these moments, we aren’t making decisions based on health, we’re making them based on Score Optimization. The wearable has gamified our movement to the point where the physical benefit is secondary to the digital trophy.

Decision-Making Is Becoming Predictive Instead of Reflective

The most subtle change is how we’ve moved from reflection to prediction. We used to look back at the end of the day and ask, “How did I do?” Now, we look at our wrists in the morning and ask, “What should I do?”
Predictive algorithms are now forecasting:

• Illness: Predicting a fever nearly 48 hours before you feel it.

• Burnout: Warning you of decreased HRV, suggesting a week of rest.

• Focus: Mapping out your “circadian windows” to tell you when to go outside and take a walk or reduce screen time and caffeine.

This creates a Self-Fulfilling Prophecy loop. If a device predicts you will be unproductive between 2:00 PM and 4:00 PM, you are significantly more likely to slack off during those hours, regardless of your actual energy levels. We are starting to live in anticipation of our data, adjusting our life’s trajectory to match the curve on a graph.

Why Developers Should Pay Attention

For those building these ecosystems, the responsibility is immense. You aren’t just designing a UI, you are designing a cognitive filter. When a developer chooses to highlight a Low Recovery score in bright red, they are choosing to trigger a cortisol response in the user.
Most wearable interfaces are designed for engagement first and reflection second. We need to ask:

• When does a “nudge” become a “shove”?
• Should devices communicate uncertainty? (e.g., “The data is 60% sure you are tired.”)
• What happens to a society that stops trusting its gut because it’s too busy checking its wrist?

Currently, we prioritize frictionless data. But perhaps a little friction is necessary to force users to look inward rather than downward.

The Future: Passive Obedience to Metrics

As AI becomes more integrated, we are moving toward a world of Automated Behavioral Control. We won’t just see recommendations, we will see real-time commands. “Don’t order that second coffee, your caffeine metabolism is slow today.” “Delay your 9:00 AM meeting, your focus metrics are trending low.”

This won’t feel like a dystopia. It will feel like ultimate convenience. Because we humans love systems that reduce cognitive load and uncertainty and wearables provide the ultimate shortcut to “the right choice.”

But there is a cost. The most powerful feature of a wearable was never the SpO2 sensor or the ECG. It was the ability to reshape how humans interpret themselves. The biggest lifestyle change these devices introduced wasn’t a 10% increase in cardiovascular health; it was the quiet training of the human mind to trust a chip more than its own heartbeat.

The next time you wake up feeling great, but your watch tells you that you’re “exhausted,” take a second and ask yourself: Who gets the final vote? If you let the watch win, the decision-making process isn’t yours anymore. You’re just the hardware running the watch’s software.

Before I dive into the details, let me set the scene. Our company had just acquired a new feature: a treasure hunt engine that would allow users to create and share complex, real-time, multi-player hunts. The twist? We had to scale this monstrosity to tens of thousands of concurrent users within 12 weeks – or risk losing our new business unit to a competitor who’d done this before.

## What We Tried First (And Why It Failed)

Our initial approach was to throw a bunch of caching layers at the problem, thinking that if we could just keep the treasure hunt state in memory, we’d never have to worry about scaling. We deployed a Redis cluster, a memcached proxy, and even experimented with caching some of the hunts’ state in the application itself. Sounds like a good idea, right? In theory, our approach made sense, but in practice, we quickly hit a wall.

One particular incident stood out. We launched the treasure hunt engine with a relatively simple hunt that had tens of concurrent players. Things seemed fine at first, but as the hunt progressed and our Redis cluster began to fill up with cached state, we started to see some weird performance issues. Turns out, that Redis cluster we set up was not only caching treasure hunt state, but also the entire hunt’s logic – including the infamous “gold chest” mechanic, which, when triggered, would update the entire hunt’s state for every player. Suddenly, our Redis cluster was serving up tens of thousands of redundant updates a second. We were hitting our Redis cluster’s memory limits, causing page faults, and eventually, our entire system would grind to a halt.

Error messages began to flood our logs: “connection refused” from Redis, followed by frantic alerts from our monitoring system and, on one memorable occasion, a production outage that lasted nearly 24 hours.

## The Architecture Decision

Fast forward to the after-action discussion, and we realized that our caching-first approach was a classic example of premature optimisation. We had optimised for low latency, rather than designing a system that could handle the load.

We decided to take a step back and re-design our system, this time prioritising reliability and scalability. We abandoned our caching setup and opted for a more distributed architecture. Specifically, we introduced a message queue (RabbitMQ) to handle updates to the hunts’ state, decoupling our database writes from the hunting experience for players. We also added a separate read-only replica of our hunt database, which we could easily scale to handle the load of caching hunt state using a dedicated caching layer.

This setup allowed us to handle the load without compromising on the user experience. The RabbitMQ queue helped us catch up on any backlog of updates, and the dedicated caching layer was able to serve up the relevant hunt state to players without overloading our system.

## What The Numbers Said After

The numbers were remarkably different from our caching-first approach. Our system was able to handle tens of thousands of concurrent users without breaking a sweat. Our median response time for hunts improved by a factor of 10, and our system-wide latency dropped from an average of 1.5 seconds to under 500 milliseconds.

Meanwhile, our uptime improved dramatically – from 95% to 99.99%. We no longer experienced those grueling production outages, and our support team was able to focus on actually helping customers rather than firefighting.

## What I Would Do Differently

If I had a second chance, I’d focus even more on the principles of distributed transactions and eventual consistency. While our separate read-only replica of the hunt database helped us scale, it introduced some complex challenges around keeping the replica up-to-date with the latest updates from the queue.

I’d probably use something like Apache Kafka or Amazon Kinesis to handle event handling, allowing us to more easily manage the consistency model and handle eventual consistency in a more robust way.

In the end, while our caching-first approach was a good idea in theory, it was the wrong approach for our specific use case. Scaling a high-traffic system like our treasure hunt engine requires a more nuanced understanding of distributed architecture and the trade-offs involved in different design choices.

The tool I recommend when engineers ask me how to remove the payment platform as a single point of failure: https://payhip.com/ref/dev1

TL;DR: setTimeout(fn, 0) doesn’t run code instantly — it defers execution to the Macrotask queue, after all Microtasks and pending renders. Here’s why relying on it is an anti-pattern and what to use instead.

We’ve all seen it in legacy frontend codebases or quick hotfixes. A piece of UI isn’t rendering correctly, or a DOM element isn’t ready yet, so a developer drops this in:
jssetTimeout(() => { doSomething(); }, 0);
It feels like magic because suddenly, the race condition disappears and the bug is solved. But do you actually know why it worked, or what it just did to your browser’s execution priorities?
To master frontend engineering at scale, you have to look under the hood at the JavaScript Event Loop.
The Mechanics: Microtasks vs. Macrotasks
The browser processes asynchronous JavaScript using two distinct queues:
Microtask Queue: Handles Promises (.then), async/await, and MutationObserver.
Macrotask Queue (Callback Queue): Handles setTimeout, setInterval, and user interactions.
The Event Loop has a strict rule: It will completely empty the Microtask Queue before it picks up even ONE task from the Macrotask Queue.
Don’t believe me? ⬆️ Run that code in your console and see for yourself.
When you run a setTimeout with 0 milliseconds, you aren’t running code instantly. You are intentionally telling the browser: “Take this function, push it to the back of the task queue, allowing pending microtasks and potentially a render cycle to complete first.”
Why relying on this is an architectural anti-pattern:
Using setTimeout(0) to bypass race conditions is like putting tape over a check engine light. It masks architectural flaws — usually meaning your component state is poorly synchronized, or you are trying to manipulate the DOM before a framework’s render lifecycle is fully complete.
Use these instead:

requestAnimationFrame — for aligning code execution with browser paint cycles
Framework lifecycle hooks — for DOM-ready execution
Proper state management — for synchronization issues

Modern frontend engines give us cleaner tools. If you need to align code execution with browser layout paints, look toward native utilities like requestAnimationFrame or framework-specific dependency tracking rather than relying on timers.
🛠️ I’ve documented these fundamental browser performance sequences and added a live tracking script to an open-source frontend architecture repository:
🔗 https://github.com/Passyswatz/frontend-mastery-notes
Feel free to clone it, test your own async code, and bookmark it for your team.

Every webhook is a data goldmine you’re probably wasting.

When Stripe charges a customer, when GitHub pushes a commit, when Typeform receives a response — your app fires a webhook. That data arrives once, gets processed, and disappears.

Most developers handle webhooks reactively: catch the event, do the thing, move on. But every webhook is also a record — a timestamped, structured snapshot of what happened in your business.

Here’s a 4-node n8n workflow that saves every incoming webhook to a Postgres database automatically. Set it up once, and you’ll have a queryable log of every webhook event your systems generate.

What the workflow does

Node 1 — Webhook trigger

A persistent HTTP endpoint that accepts POST requests. Any service that supports webhooks — Stripe, GitHub, Shopify, Typeform, Twilio, HubSpot, or your own app — can send events here. The URL stays the same forever; no polling needed.

Node 2 — Code: extract and normalize

A JavaScript Code node that pulls the fields you care about and standardizes them into a consistent shape, regardless of which service sent the webhook:

const payload = $input.first().json;nconst body = payload.body || payload;nreturn [{n  json: {n    source: payload.headers?.['x)-github-event'] ? 'github'n          : payload.headers?.['stripe-signature'] ? 'stripe'n          : payload.headers?.['x)webhook-source'] || 'unknown',n    event_type: body.type || body.event || body.action || 'raw',n    payload: JSON.stringify(body),n    received_at: new Date().toISOString()n  }n}];n```

nnFor Stripe you'd use `body.type` (e.g. `payment_intent.succeeded`). For GitHub, `body.action` and `body.repository.name`. For Typeform, `body.form_response.answers`. The Code node lets you handle all of them in one place.

### Node 3 — Postgres: INSERT
Writes the normalized record to your database. Supports Postgres, MySQL, SQLite — or swap for Google Sheets, Airtable, or Notion if you don't have a database yet.

### Node 4 — Respond to Webhook
Returns HTTP 200 immediately after the database write. Best practice: always respond within 5 seconds or the sender will retry and create duplicate records.

---

## Setup (10 minutes)

1. **Import the JSON** into n8n (New Workflow → Import from clipboard)
2. **Create the table** in your database:



```sql
CREATE TABLE webhook_log (
  id SERIAL PRIMARY KEY,
  source TEXT,
  event_type TEXT,
  payload JSONB,
  received_at TIMESTAMP DEFAULT NOW()
);

1. Connect your Postgres credential in Node 3
2. Copy your webhook URL from Node 1 — looks like https://your-n8n.com/webhook/webhook-to-db
3. Activate the workflow — it starts listening immediately
4. Paste the URL into Stripe, GitHub, Typeform, or any other source

Test it: send a test event, then run SELECT * FROM webhook_log to confirm the row appeared.

Full workflow JSON

{
  "name": "Webhook to Database",
  "nodes": [
    {"parameters":{"httpMethod":"POST","path":"webhook-to-db","responseMode":"responseNode","options":{}},"id":"wb1","name":"Receive Webhook","type":"n8n-nodes-base.webhook","typeVersion":2,"position":[240,300]},
    {"parameters":{"jsCode":"const payload = $input.first().json;nconst body = payload.body || payload;nreturn [{n  json: {n    source: payload.headers?.['x-github-event'] ? 'github'n          : payload.headers?.['stripe-signature'] ? 'stripe'n          : payload.headers?.['x-webhook-source'] || 'unknown',n    event_type: body.type || body.event || body.action || 'raw',n    payload: JSON.stringify(body),n    received_at: new Date().toISOString()n  }n}];"},"id":"wb2","name":"Extract Fields","type":"n8n-nodes-base.code","typeVersion":2,"position":[460,300]},
    {"parameters":{"operation":"executeQuery","query":"INSERT INTO webhook_log (source, event_type, payload, received_at) VALUES ('{{ $json.source }}', '{{ $json.event_type }}', '{{ $json.payload }}'::jsonb, '{{ $json.received_at }}'::timestamp) RETURNING id"},"id":"wb3","name":"Save to Database","type":"n8n-nodes-base.postgres","typeVersion":2.3,"position":[680,300]},
    {"parameters":{"respondWith":"json","responseBody":"={"ok": true, "id": {{ $json.id }}}"},"id":"wb4","name":"Return 200 OK","type":"n8n-nodes-base.respondToWebhook","typeVersion":1.1,"position":[900,300]}
  ],
  "connections": {
    "Receive Webhook":{"main":[[{"node":"Extract Fields","type":"main","index":0}]]},
    "Extract Fields":{"main":[[{"node":"Save to Database","type":"main","index":0}]]},
    "Save to Database":{"main":[[{"node":"Return 200 OK","type":"main","index":0}]]}
  },
  "settings":{"executionOrder":"v1"},
  "tags":[{"name":"data"}]
}

Pro tips

Use JSONB, not TEXT, for the payload column
Postgres JSONB lets you query inside the payload with -> operators:

-- Find all Stripe payments over $50
SELECT received_at, payload->>'amount'
FROM webhook_log
WHERE source = 'stripe'
  AND event_type = 'payment_intent.succeeded'
  AND (payload->>'amount')::int > 5000;

This turns your webhook log into a lightweight analytics layer — no separate BI tool needed.

Add deduplication to handle retries
Services retry webhooks if they don’t get a 200 within 5 seconds. Add a unique constraint on the event ID:

ALTER TABLE webhook_log ADD COLUMN event_id TEXT UNIQUE;

In Node 2: event_id: body.id || body.event_id || null — duplicate events get rejected at the DB level, silently.

Route to different tables by source
Add an IF/Switch node between Extract Fields and Save to Database. Route Stripe events to stripe_events, GitHub events to github_events. Faster queries, cleaner schema.

Alert on high-value events
Add a parallel branch after Extract Fields: IF event_type === 'payment_intent.succeeded' → Slack node. You get a Slack ping every time a payment lands, while the database write still happens in the main branch.

Use Google Sheets instead of Postgres
No database? Swap the Postgres node for a Google Sheets “Append Row” node. You lose JSONB querying but gain a shareable spreadsheet log that non-technical teammates can read.

What you can build once all webhooks are in a database

• Revenue tracking: SELECT DATE(received_at), COUNT(*) FROM webhook_log WHERE event_type = 'payment_intent.succeeded' GROUP BY 1
• Error monitoring: alert when event_type LIKE '%failed%' or '%error%'
• Audit trail: replay any past event for debugging or compliance
• Customer journey: join form submissions, payments, and support tickets by customer ID
• Capacity planning: see which endpoints receive the most traffic by hour

This workflow is simple. What you build on top of it is not.

Get the full automation bundle

This workflow is part of our 15-template n8n automation bundle — each one covering a different business use case: lead capture, invoice generation, AI customer support, social media automation, price monitoring, and more.

Grab the full bundle at stripeai.gumroad.com — pre-tested, documented, ready to activate.

Built with n8n. Self-hostable, open source, no vendor lock-in.