What if you used a robot friend to get it done in an hour instead?

Who You Might Be

This article is aimed at non-technical audiences with enough technical seeds so developers new to using AI can also run with it to create their own projects. I was prompted to write this by a recent project for a client, a React/Web application that works with Gmail to do automatic categorization (sample code is coming soon!).

Note: AI-assist tools allowed me to complete this project in a weekend, just using their basic functionality of prompted code generation. Think of the process as having a very junior developer at your beck and call, telling them what to do and then reviewing logical units of work to make sure they're correct.

You can use a lot of different tools for this: Built in chat windows in Cursor and Windsurf, or completely separate command-line utilities like Claude Code . My preference is Claude Code, but I encourage you to experiment and see which one you like best!

Some Scaffolding

We're going to skip the scaffolding of a basic React application and using OAuth to log in with Gmail and assume we have a working web app with 3 display areas: Our connected e-mail accounts, some categories we've defined, and the e-mails themselves.

For resiliency, we've designed our application with Anthropic as the primary API provider and OpenAI as the fallback: If we can't connect to Anthropic, we'll use OpenAI instead.

Robot Friends Start Helping

We let the user define their own categories, a logical object that has a friendly name we define and also a description of what kind of e-mails should go into it. When a new e-mail comes in, we ask our AI partner to read it and place it in the appropriate category, or the 'general' category if none match.

We also have AI give us quick summaries of each e-mail in our right-most pane: It reads the e-mail, and then generates a short summary for us. In the actual app if we click on the e-mail itself we get the original message text.

Now things get interesting: We want to make AI Agents that will process unsubscribe requests like a worker processing a job (you might be familiar with this through technologies like RabbitMQ, BullMQ or one of many other asynchronous worker systems).

These agents have to look through an email and find the unsubscribe link. If the site we're trying to unsubscribe from is really clever, they might only let us do this after ticking some boxes or doing some other complex UI interaction.

There's also a very specific wrinkle here: Our AI Agents have to 'look' at a web page to see all the controls we might have to interact with and/or success text that indicates we've unsubscribed. That means using a virtual web browser to view and take a screenshot of the unsubscribe page.

Some Virtual Browser Wrinkles

There are software packages that facilitate this like Playwright and Puppeteer, but they come with a catch: They don't work very well with serverless compute. It's highly recommended you look at a containerized backend like Railway instead so you don't run into any issues.

You can look at a hosted service like Browserless which lets you connect to a hosted web browser you can do things with, but it can be expensive if you want to connect to more than 1 virtual browser at a time.

How to create your job system will not be covered in this article, so we'll assume you have a working asynchronous task system that is ready to accept instructions.

Here's how our robot friend will specifically unsubscribe for us:

We'll have to generate a prompt here, or how we're going to specifically tell our robot friend to do this for us. I'm going to leave this as an exercise for you (if you want to skip this part, you can ask Claude or ChatGPT to help you with a pretty good starter prompt).

Optimizing prompts is a skill and this is a great project to develop that skill, watching what happens as you change and optimize the prompt to get our robot friend to do what you want.

For this project I ended up adding a bit of UI sugar in marking e-mail messages that launched a successful unsubscribe operation in green, ones in progress as yellow and failed ones in red. Feel free, though, to use whatever UI pattern you prefer!

I hope this article has been helpful for you, if only to learn about some things that our robot friends can do for us! Can you think of other ways they might be able to save us a lot of time?

I needed to use an external component for a Next.JS project I'm working on: mixmotion-player which is a React front-end for assets stored on Mixcloud.

Mixmotion is a client-side only react component, meaning it has some dependencies that make it tricky to integrate with something that does server side rendering like Next. It will depend on globals like window which don't exist on the server.

Here's how I got it to work, and necessary steps which you will probably have to do if you're integrating a similar React component.

1) I was unfamiliar with the component, so I created a new blank React project running on Vite.
2) I imported Mixmotion into that project using npm install mixmotion-player.
3) I used boilerplate code from the Mixmotion GitHub page, and was soon listening to sick beats in my browser.

Things were going well! Then I tried integrating it with my existing Next project and ran into issues.

First, an easily fixable one: Mixmotion prefers React 18.2.0 so I edited package.json to use those React versions.

Then the hard one: Mixmotion not finding the window global on server-side renders.

There are a couple different ways to deal with this, I've found using dynamic imports to be the cleanest.

I created a dynamic wrapper for the Mixmotion component:

import dynamic from "next/dynamic";

const MixmotionPlayer = dynamic(() => import("mixmotion-player").then((mod) => mod.MixmotionPlayer), {
    ssr: false,
});

export default MixmotionPlayer;

We're following a fairly standard flow here:

-Importing dynamic from a Next module
-Creating a container via MixmotionPlayer for our component
-Calling the dynamic function, which in turn imports a named export (mod stands for module here)
-Passing an option of ssr: false which tells Next that this should not be included in server side rendering.

We're all set, right? Not quite yet.

We've dealt with runtime issues, but we have to keep in mind that by default Next uses webpack to create the production bundle. This will work with next dev, but will throw an error when using next build about webpack being unable to resolve the module.

When you deploy to a service like Vercel, you'll be taking the bundle generated by next build and not using next dev, so this is an issue. We can fix it by telling Next not to include this module in the bundle.

You'll need to change your next.config.ts or .js to something like the following (this example uses TypeScript):

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  reactStrictMode: true,

  webpack: (config, { isServer }) => {
    if (!isServer) {
      config.resolve.fallback = {
        'mixmotion-player': false,
      };
    }

    return config;
  }

};

export default nextConfig;

Webpack is checking if we're doing a server or client side build, and if it's a client build we're telling Webpack to not try to resolve the mixmotion-player package.

It might seem odd that we're excluding the client side! After all, how can the client work if this package is excluded?

It's only being excluded from Next's static analysis at build time, not from the project entirely. It will still be dynamically loaded by the client at runtime.

Now that next build works, I was able to deploy the project to Vercel via vercel --prod. And voila: Sick beats on Next via mixmotion-player!

Having been in information security in various capacities for a while, my skin itches a bit when I see this discourse pop up in web3. Many look upon web3 as the wild west, not having quite attained that arbitrary point of maturity to where its product can be intrinsically trusted. Some of crypto's PR woes stem from this, and unfortunate incidents when opportunism drove decisions more than responsibility did.

Ironically, the PR issue that plagues web3 has created space for some unhealthy attitudes. After FTX (and many other things), the general public associates crypto with many unfavourable words, 'scam' being one of them. Bloggers have created enough FUD around NFT's that a lot are willing to write any project off as a ponzi. In this kind of environment, it's tempting to view lesser security issues as just moving fast, breaking things.

Greenfield industries, startups, and other environments where speed is essential do require some reimagining of the kind of mindset that might be expected at Google or Salesforce. There often isn't time or resources for multiple levels of architecture review, steering committees, or formal verification audits. In terms of responsibility, Engineering is responsible to the company for shipping.

This should, however, not be the end of the security discussion. In my view, if you're going to reap the benefits of building in web3, you have some minimum level of responsibility to the rest of us. My initial impetus for writing this was driven by ChatGPT generating solidity vulnerabilities, but reading some commentary that 'web3 startups don't have time for security' is what really made me put fingers to keyboard here.

The all or nothing attitude really puzzles me. Yes, some of the more elaborate or less time-consuming security products cost money, but there are alternatives. Setting up CI/CD security pipelines is doable in a weekend, and there are low-cost auditors. If you hit up crypto twitter or Farcaster, you'd be very likely to find an outside set of eyes that will have a look at your code for free.

The dynamics in web2 are certainly different, especially with an established customer base and/or financial systems. If you break that kind of trust with relative normies, who are more concerned about their financial data being secure than some of the loftier aspirations of web3, you probably aren't getting it back. As a result, meticulous testing cycles, staging environments, and approval matrices slow things down.

Things are different in web3 and startup land in general, and even web3 security auditors will say that some do take worrying about security too far. It's always a tradeoff, and the most securely written solidity will end up never being used if your startup doesn't meet timelines or can't raise. These are nuances that bend and/or break traditional security models, and 'we don't have time for security' is the easy way around them.

There's always some minimum level of effort than can be put in to make things more secure than zero effort would result in. No one gets it perfect, Okta's woes over the last few years have certainly shown that's equally true for web2. Doing nothing, though, isn't good enough, as Gordon Ramsey might say.

There are also many ways of doing something. There is no end of Solidity content including security, which can be adapted for lunch and learns, if your startup engages in them. If you don't have a devops person / don't have the resources to hire one, you can post bounties for specific tasks. If you have social media talent and presence, you can probably content your way to having talented people red-team your contracts.

With all due respect to the incredible importance of speed and shipping in a space like web3: Yes, you do have time for security.