DEV Community: Jim Zandueta

I Built an AI App That Gives You Superpowers, But Makes Them Useless

Jim Zandueta — Wed, 08 Apr 2026 03:51:52 +0000

This is a submission for the DEV April Fools Challenge

What I built

I built a full-stack AI app that gives you the superpower you ask for, then ruins it with one tiny condition.

You open the site.
You rub a magical lamp.
A genie shows up.
You make a wish.
The app grants it in a way that makes the whole thing basically useless.

cursed-powers--jimzandueta.replit.app

You can become invisible, but only your internal organs.
You can shape-shift, but only into a slightly uglier version of yourself.
You can hear other people's thoughts, but only in extinct languages.

So yes, it works.

It just works toward a completely worthless outcome.

The idea was simple. I wanted to interpret "useless" a little sideways.

Instead of making something broken, I made something polished whose output is useless on purpose.

The app does what it says. The infrastructure is real. The end result is still nonsense.

So I did not build a useless app.

I built an app that mass-produces uselessness.

And because I apparently cannot leave a joke alone once it starts working, I also over-engineered it.

Demo

Code

The repo includes the app code, infra setup, docs, ADRs, API design, tests, and enough delivery process to make the whole thing feel weirdly official.

jimzandueta / cursed-powers

Cursed Powers

Every superpower has a catch™

Cursed Powers is a full-stack web application that combines AI with interactive storytelling. Users rub a magic lamp to summon a genie, make a superpower wish, and receive a hilariously cursed interpretation of their wish powered by AI.

The engineering is production-grade. The usefulness is thoroughly cursed.

Features

Interactive Lamp Experience: Animated lamp-rubbing interface that triggers genie summoning
Dual AI Providers: Fallback-capable integration with Google Gemini 2.5 Flash and OpenAI GPT-4o-mini
Security-First Backend: Rate limiting, abuse detection, request signing, CAPTCHA verification, and content moderation
Real-Time Results: WebSocket-ready architecture with progressive result streaming
Enterprise Deployment: Production-ready infrastructure with AWS ECS Fargate, CloudFront CDN, WAF, and automated scaling
Comprehensive Testing: 192 unit tests (100% API coverage) + 14 E2E browser tests
Type-Safe: 100% TypeScript with strict mode across frontend and backend

Architecture

                         ┌──────────────────────────────┐
                         │        CloudFront CDN        │
                         │

…

View on GitHub

How I built it

Because the infrastructure is part of the punchline, I wanted to show not just the app, but the machinery behind it.

This project only works as a joke if the output is ridiculous and the implementation is treated with an unreasonable amount of seriousness.

Architecture, unfortunately

Under the magical lamp and cursed wishes, this project runs on a stack that is much more serious than the idea deserves.

That is part of the joke too. This entire system exists to reliably produce unusable superpowers.

                         ┌──────────────────────────────┐
                         │        CloudFront CDN        │
                         │     + WAF (4 rule groups)    │
                         └──────────────┬───────────────┘
                                        │
                         ┌──────────────▼─────────────────┐
                         │     Application Load Balancer  │
                         │   (TLS 1.3, path-based routing)│
                         └───────┬──────────────┬─────────┘
                                 │              │
                    /api/*       │              │    /*
                   ┌─────────────▼──┐   ┌──────▼────────────┐
                   │   ECS Fargate  │   │   ECS Fargate     │
                   │   Fastify API  │   │   Next.js Web     │
                   │                │   │                   │
                   │  ┌──────────┐  │   │  Security Headers │
                   │  │ Helmet   │  │   │  HSTS, CSP, etc.  │
                   │  │ Rate Lim │  │   └───────────────────┘
                   │  │ Circuit  │  │
                   │  │ Breakers │  │
                   │  └──────────┘  │
                   └───────┬────────┘
                           │
              ┌────────────▼────────────┐
              │    EFS (Encrypted)      │
              │    SQLite + WAL mode    │
              │    Daily backups        │
              └─────────────────────────┘
                           │
            ┌──────────────┼──────────────┐
            │              │              │
      ┌─────▼─────┐ ┌─────▼─────┐ ┌─────▼──────┐
      │  Gemini   │ │  OpenAI   │ │  OpenAI    │
      │  2.5 Flash│ │  GPT-4o   │ │  Moderation│
      │ (primary) │ │  (backup) │ │  API       │
      └───────────┘ └───────────┘ └────────────┘

If someone only looked at the infrastructure, they might assume it powers something financially important.

It does not.

It powers a genie that grants wishes badly.

Frontend

On the surface, the app needed to feel magical before it felt stupid.

The frontend uses:

Next.js 15
React
Tailwind CSS v4
Framer Motion

I did not want this to feel like a generic AI textbox with a lamp pasted on top. I wanted it to feel a little ceremonial: arrive, rub the lamp, summon the genie, make a wish, then wait for the system to ruin it with confidence.

So the frontend is responsible for the parts that make the joke land:

lamp animation
genie reveal
wish input flow
result rendering
validation
API integration
request handling
enough theatricality to make the whole thing feel intentional

Backend

Once the frontend sets the mood, the backend does the deeply unserious serious work.

The backend uses:

Fastify 5
Drizzle ORM
SQLite
Zod
Pino
Helmet
@fastify/rate-limit
Cloudflare Turnstile verification

It handles:

wish submission and validation
AI orchestration
cursed power generation
result retrieval
gallery and random wish endpoints
health checks
moderation
rate limiting
request validation
diagnostics

Honestly, the backend is more serious than the premise deserves.

That was deliberate.

If the output is nonsense, the system producing that nonsense should still be solid.

Google AI / Gemini usage

At the center of all this is the actual wish-ruining engine.

Gemini is the main model behind the app.

I used:

Google Gemini 2.5 Flash as the primary model
OpenAI GPT-4o-mini as the fallback provider
OpenAI Moderation in the safety pipeline

The AI flow is not just "say something random and funny." It follows a simple structure:

wish → interpret → curse → return a technically valid but practically useless power

That constraint helped a lot. The outputs became more consistent, easier to read, and usually much funnier.

The genie is not denying your wish.

The genie is honoring it as maliciously as possible.

Ridiculous over-engineering, on purpose

At this point, the second joke becomes obvious:

the implementation is wildly disproportionate to the value of the product.

So naturally, this cursed superpower generator includes:

npm workspaces + Turborepo
a shared type-safe schema package
OpenAPI 3.1
9 architecture decision records
Terraform-managed AWS infrastructure
CloudFront CDN
AWS WAF
an Application Load Balancer with TLS 1.3
ECS Fargate for both web and API
encrypted EFS-backed SQLite in WAL mode
multi-stage Dockerfiles
docker-compose for local development
CI with typecheck, lint, unit tests, E2E tests, and commitlint
a tag-triggered release pipeline
Husky pre-commit, commit-msg, and pre-push hooks
Conventional Commits enforcement
a deep health check endpoint
a runbook
an incident response guide
a service level agreement
HTCPCP compliance

A lot of joke projects stop at the concept.

I wanted this one to keep going until the engineering itself became part of the punchline.

Did I mention it also has 100% unit test coverage?

Security, because apparently even cursed wishes need governance

And since I was already making terrible but committed decisions, I also spent real time on security.

That includes:

CloudFront + AWS WAF
Helmet security headers
rate limiting
Cloudflare Turnstile CAPTCHA support
Zod schema validation
AI provider circuit breakers
content moderation
CORS configuration
proxy awareness for real client IP handling
vulnerability reporting documentation
dependency monitoring through CI and GitHub alerts

Is this more security planning than most genie interactions require?

Yes.

Was I going to stop because of that?

Obviously not.

Teapot compliance

Is 418 and teapot a super power?

Prize category

I would like to be considered for:

Best Google AI Usage
Best Ode to Larry Masinter
the main DEV April Fools Challenge

This app is not useless because it is broken.

It is useless because it is very good at producing unusable results.

That is the whole bit.

Some people use software to solve meaningful problems.

I used software to build a scalable platform for granting wishes badly.

The system is stable.

The infrastructure is serious.

The output is useless.

That is exactly what I set out to build.

The Codex Setup That Worked for Us: Memory, Manifests, and Structured Context

Jim Zandueta — Wed, 01 Apr 2026 07:14:45 +0000

The past few weeks have been wild.

Our team recently adopted AI-assisted programming (not vibe-coding). We wanted speed, consistency, and fewer repetitive tasks.

What we got in week one was... chaos.

TL;DR
We had inconsistent AI output across teammates, treated it as a systems problem, applied Agentic SDLC principles, and built a .codex structure that made Codex outputs far more consistent.

Quick Jump

What worked (and what didn’t)
The shift: Agentic Software Development Lifecycle
What’s inside .codex (and why it matters)
How we used it in this repo
What’s next

Even with detailed technical tickets, our AI agents kept producing outputs that didn’t line up:

different naming conventions
different folder structures
different approaches to the same problem
different error-handling and testing styles

Every merge felt like stitching code from three different universes.

Week one energy: us trying to keep standards while random AI output keeps walking by.

What worked (and what didn’t)

We tested different setups.

A strong CLAUDE.md helped a lot early. Claude Opus was excellent at reasoning and breaking work down step by step.

The issue for us was practical: limits and timeouts.

Since our company sponsors Codex, we moved to Codex as our main tool. First impression? A bit lackluster compared to Claude out of the box.

That pushed us to a better question:

Maybe this isn’t just a model problem. Maybe it’s a system problem.

The shift: Agentic Software Development Lifecycle

Quick diff:

Traditional SDLC: mostly human implementation through linear phases.
A-SDLC: human + AI-agent collaboration in tight feedback loops.

In A-SDLC, developers don’t just write code. We orchestrate:

guardrails
context
fast reviews
memory updates

And yes, we’re actively applying these principles in real day-to-day work, not just talking about them:

better prompts
tighter feedback loops
stronger project memory
clear constraints, patterns, and checklists

Once we treated this as a systems problem, output quality improved fast.

That’s why I built this boilerplate: to showcase the .codex setup that worked best for us.

Repo: github.com/jimzandueta/codex-nestjs

What’s inside `.codex` (and why it matters)

This isn’t just a random folder. It’s the operating system for consistent AI-assisted engineering.

.codex/
  START_HERE.md
  RULES.md
  MANIFEST.yaml
  instructions/
  patterns/
  anti-patterns/
  checklists/
  skills/
  prompts/
  templates/
  overrides/
  memory/

1) `START_HERE.md` + `RULES.md`

These are your baseline guardrails.

## Output Rules
1. Reuse existing patterns before inventing new ones.
2. Keep diffs minimal.
3. Never commit secrets.

This alone prevents a lot of “same task, five coding styles” situations.

2) `MANIFEST.yaml`

This is context routing. It tells the agent what to load for each task type.

task_routes:
  new-feature:
    read:
      - .codex/instructions/global.md
      - .codex/patterns/repo-structure.md
      - .codex/patterns/error-handling.md
    skills:
      - .codex/skills/new-feature/SKILL.md

So agents don’t start cold. They start with the right playbook.

3) `instructions/`, `patterns/`, `anti-patterns/`

instructions/: how to work
patterns/: preferred way to build
anti-patterns/: what to avoid

Think of this as turning tribal team knowledge into repeatable, machine-readable engineering practice.

4) `checklists/`, `skills/`, `prompts/`, `templates/`

This is the day-to-day execution layer:

checklists/: quality gates
skills/: repeatable workflows
prompts/: reusable prompt scaffolds
templates/: starter artifacts

Example checklist snippet:

## Tests
- [ ] New logic has happy path + failure test
- [ ] Coverage stays at 100% threshold
- [ ] No flaky tests introduced

5) `overrides/`

This lets you keep generic Codex assets while declaring project reality.

Example:

generic pattern: “recommended structure”
project override: “this NestJS repo uses src/common, src/clients, src/modules, etc.”

6) `memory/` (the secret sauce)

This is where consistency compounds:

memory/project-facts.md → stable project truths
memory/decisions.md → ADR-style decisions/tradeoffs
memory/learned-patterns.md → recurring conventions discovered during work

As new decisions are made between the developer and AI agent, memory gets updated so future tasks inherit the same context and tradeoffs.

A realistic flow:

Developer: “We need requestId in logs for traceability.”
Agent: “Two options: AsyncLocalStorage or explicit propagation.”
Team decision: explicit propagation first (simpler + easier to test).
Memory updates: ADR + project convention + learned pattern.

Sample ADR:

### ADR-002: Standardize request correlation IDs in HTTP logs

**Date**: 2026-04-02
**Status**: Accepted

**Context**: Debugging incidents was slow because logs across layers were hard to correlate.
**Decision**: Add `requestId` at the HTTP boundary and propagate it through services/clients.
**Consequences**: Better traceability, with slight method-signature overhead.

Sample project facts update:

## Conventions
- Logging: include `requestId` in structured logs for HTTP flows.
- Request context: generate/forward `x-request-id` at ingress and propagate downstream.

Sample learned pattern:

### LP-001: Propagate requestId from boundary to integrations

**Observed**: Missing correlation fields made multi-step failures harder to debug.
**Rule**: Controllers create context; services/clients forward `requestId`; logs include it at each layer.

This memory layer is the difference between “new agent, same mistakes” and “new agent, same team brain.”

How we used it in this repo (GitHub)

Using this .codex setup, we built a NestJS sample HTTP server with consistent architecture and quality gates:

clear boundaries (common, clients, integrations, modules, http, errors)
validated runtime config (HOST, PORT, NODE_ENV, LOG_LEVEL)
structured logging
reusable HTTP client with timeout/retry
typed external API errors + global exception filter
sample feature module (posts) using JSONPlaceholder
strict tests with 100% coverage thresholds
open-source docs (LICENSE, CONTRIBUTING, CODE_OF_CONDUCT, SECURITY)

So this repo isn’t just “another Nest starter.”

It’s a working example of structured AI-assisted delivery.

One important note

Codex setups are usually stack-specific.

This .codex is tuned for a NestJS HTTP app. I maintain a different Codex baseline for Terraform/infrastructure because workflows, anti-patterns, and quality gates are different.

Same core idea, different playbook.

What’s next

I’ll keep evolving this repo with:

richer feature module examples
better integration patterns
stricter review automations
stack-specific Codex variants
deeper AI-agent orchestration experiments using open-source tools like LangChain, Langfuse, and local models

If your team is in that “week one AI chaos” phase, start with structure first.

Model quality matters, but system quality matters more.

IMPORTANT: Here's a picture of my cat!

How to Allow Users to Upload and Download Data from AWS S3 Without Direct Access Using Pre-Signed URLs?

Jim Zandueta — Sat, 24 Dec 2022 05:49:34 +0000

Introduction

Amazon Simple Storage Service (AWS S3) is a popular cloud storage service that allows users to store and retrieve data from a variety of sources. While S3 buckets are set to public by default, there are times when it is necessary to restrict access to specific users or groups. Direct access to the bucket in these scenarios may pose security risks and limit flexibility.

Problem

Direct access to an AWS S3 bucket necessitates exposing the AWS access keys and secret keys to users, which can result in unauthorized access to the bucket and its contents. Furthermore, using this method, it may be impossible to control specific actions or limit access time.

Solution

Pre-signed URLs provide a secure solution by allowing users to access specific objects in the bucket without exposing the AWS access keys and secret keys. Pre-signed URLs can also be used to restrict specific actions that users can take and to limit the amount of time that a user has access to the data.

To generate pre-signed URLs in TypeScript, you can use the aws-sdk package, which provides a getSignedUrl method that can be used to generate a pre-signed URL for a specific S3 object. Here's an example of how to use getSignedUrl to generate a pre-signed URL for downloading an S3 object:

// Generate a pre-signed URL for an S3 object
async function generatePresignedUrl(
  bucket: string,
  key: string,
  expiration: number
): Promise<string> {
  const s3 = new AWS.S3()
  const params = {
    Bucket: bucket,
    Key: key,
    Expires: expiration,
  }
  const url = await s3.getSignedUrlPromise('getObject', params)
  return url
}

// Example usage
const bucket = 'my-s3-bucket'
const key = 'path/to/my/object.jpg'
const expiration = 60 // URL will expire in 60 seconds
const url = await generatePresignedUrl(bucket, key, expiration)
console.log(url) // Outputs a pre-signed URL that can be used to access the object

To generate a pre-signed URL for uploading an S3 object, you can use the putObject method in a similar way:

import * as AWS from "aws-sdk";
import * as express from "express";

// Configure the AWS SDK with your S3 bucket's credentials
AWS.config.update({
  accessKeyId: "ACCESS_KEY_ID",
  secretAccessKey: "SECRET_ACCESS_KEY",
});

const s3 = new AWS.S3();

// Create an Express.js router
const router = express.Router();

// Route for generating a pre-signed URL for uploading a file to S3
router.post("/upload", async (req, res) => {
  try {
    // Check if the file was included in the request
    if (!req.body.file) {
      throw new Error("No file provided");
    }

    // Get the file and other parameters from the request body
    const { file, bucket, key } = req.body;

    // Generate a pre-signed URL for uploading the file to S3
    const params = {
      Bucket: bucket,
      Key: key,
      ContentType: file.type,
      ACL: "private", // Set the ACL to "private"
    };
    const url = s3.getSignedUrl("putObject", params);

    // Send the pre-signed URL back to the client
    res.send({ url });
  } catch (error) {
    // Send an error response if something went wrong
    res.status(500).send({ error: error.message });
  }
});

// Export the router
export default router;

---

// Example Usage
import * as axios from "axios";

// Function to upload a file to S3 using a pre-signed URL
async function uploadFile(url: string, file: File): Promise<void> {
  // Set the headers for the request
  const headers = {
    "Content-Type": file.type,
  };

  // Make the PUT request to the pre-signed URL
  const response = await axios.put(url, file, { headers });

  // Check the status of the response
  console.log(response.status); // Outputs 201 if upload was successful
}

// Example usage
const file = new File(["Hello, world!"], "hello.txt", { type: "text/plain" });
const url = "<server_url>/upload";
await uploadFile(url, file);

Conclusion

Pre-signed URLs are a convenient and secure way for users to access data in an AWS S3 bucket without granting direct access. To use pre-signed URLs, use the AWS SDK to generate a URL for a specific object in the bucket. The generated URL can then be provided to the user, who can use it to access the object within the time period specified in the URL.

References

How to connect to the same host with different SSH keys?

Jim Zandueta — Tue, 16 Aug 2022 14:12:00 +0000

Required Reading:

Generate an SSH key pair

Optional Reading:

None

Setup your SSH configuration file

When connecting to a remote server via SSH, we would use the command line to specify the remote user name, hostname, and port, as shown below:

$ ssh tony@avengers.com -p 4321

We can connect to the server using the same options as in the previous command by typing ssh avengers after adding the following lines to your ~/.ssh/config:

Host avengers
    HostName avengers.com
    User tony
    Port 4321

We can also specify which SSH key to use when connecting to a specific server in the configuration file by setting IdentityFile:

Host avengers
    HostName avengers.com
    User tony
    Port 4321
    IdentityFile ~/.ssh/id_rsa_avengers

Host marvel
    HostName marvel.com
    User tony
    Port 8080
    IdentityFile ~/.ssh/id_rsa_marvel

The use of IdentityFile is especially useful when connecting to the same hostname with different SSH keys. A real-world example would be having multiple Github accounts, such as personal and work:

Host github_personal
    HostName github.com
    IdentityFile ~/.ssh/github_personal

Host github_work
    HostName github.com
    IdentityFile ~/.ssh/github_work

IdentityFile ~/.ssh/id_rsa 
#default ssh key to use for all other hosts

Using the configuration file above, we can clone repositories from your personal Github account with:

$ git clone git@github_personal:tonystark/ultron.git

Notice that instead of @github.com as the host name, we use @github_personal as defined in the configuration file.

Updating the configuration file:

Open your favorite terminal
Create/Open the SSH configuration file

$ nano ~/.ssh/config

Resources

git config file syntax

How to generate a secure SSH key pair?

Jim Zandueta — Tue, 16 Aug 2022 13:39:00 +0000

Required Reading:

None

Optional Reading:

None

Generate an SSH key pair

Open your favorite terminal
Run the ssh-keygen command

$ ssh-keygen -t rsa -b 4096 -C "tonystark@avengers.com"

INFO: For increased security, the type flag -t rsa and the bits flag -b 4096 are required. The comment flag -C "tonystark@avengers.com" allows us to easily identify who owns the SSH key.

Specify the key file name. Default is id_rsa
Enter a passphrase *optional

WARNING: If you already have a default SSH key ~/.ssh/id_rsa, DO NOT OVERWRITE IT. If you are not careful, you will lose SSH access to your cloud servers and git platforms. Instead, give your new SSH key a new name, such as id_rsa_avengers.

Resources

ssh-keygen | SSH Tutorial

How to setup your global (and local) git profile?

Jim Zandueta — Tue, 16 Aug 2022 13:29:00 +0000

Required Reading:

None

Optional Reading:

None

Setup your git profile

Open your favorite terminal
Set your git username

$ git config --global user.name "Tony Stark"

Set your git email

$ git config --global user.email tonystark@avengers.com

Set your git editor *optional

$ git config --global core.editor nano 
# you can also use emacs (nostalgic) or vim (adventurous). 
# Vim is the default editor.

Review your settings

$ git config --list --show-origin

The global flag --global will apply the configuration to the current operating system profile/user. If you want to apply your configuration at the local level, navigate to the project's root directory (where the.git folder is located) and run the git config commands without the global flag, or use the local flag --local to be more verbose.

Resources

macOS: Moving Your Notification to a Different Display

Jim Zandueta — Fri, 08 May 2020 09:26:07 +0000

My current display configuration includes my Macbook to the right and a 27" BenQ Monitor in front of me. The larger screen houses all of my work-related applications, while the smaller one houses my calendar, calculator, and Spotify.

For as long as I can remember, all of my notifications would appear on the screen of my Macbook. I never thought about it before, but after getting in trouble for missing several critical Slack messages, I realized I needed to do something about it.

I did some research and here's what I discovered:

Setting up multiple displays on macOS is a simple process. Simply navigate to System Preferences > Displays > Arrangement and drag the screens to the desired location.

Take note of the white bar on top of the small screen icon. That, believe it or not, is the Menu Bar. It handles a lot of things, including notifications!

I simply dragged it to the screen icon on the left, and after a few flashes, my 27" display became my main monitor (displaying notifications), and my Macbook became the extension monitor.

However, moving the menu bar icon will rearrange your desktop. So, if you have your applications organized across multiple desktops, consider cleaning them up first.

I hope this was helpful. Happy coding!

Cheers!

DEV Community: Jim Zandueta

I Built an AI App That Gives You Superpowers, But Makes Them Useless

What I built

Demo

Code

jimzandueta / cursed-powers

Cursed Powers

Features

Architecture

How I built it

Architecture, unfortunately

Frontend

Backend

Google AI / Gemini usage

Ridiculous over-engineering, on purpose

Security, because apparently even cursed wishes need governance

Teapot compliance

Prize category

The Codex Setup That Worked for Us: Memory, Manifests, and Structured Context

Quick Jump

What worked (and what didn’t)

The shift: Agentic Software Development Lifecycle

What’s inside .codex (and why it matters)

1) START_HERE.md + RULES.md

2) MANIFEST.yaml

3) instructions/, patterns/, anti-patterns/

4) checklists/, skills/, prompts/, templates/

5) overrides/

6) memory/ (the secret sauce)

How we used it in this repo (GitHub)

One important note

What’s next

IMPORTANT: Here's a picture of my cat!

How to Allow Users to Upload and Download Data from AWS S3 Without Direct Access Using Pre-Signed URLs?

Introduction

Problem

Solution

Conclusion

References

How to connect to the same host with different SSH keys?

Setup your SSH configuration file

Resources

How to generate a secure SSH key pair?

Generate an SSH key pair

Resources

How to setup your global (and local) git profile?

Setup your git profile

Resources

macOS: Moving Your Notification to a Different Display

What’s inside `.codex` (and why it matters)

1) `START_HERE.md` + `RULES.md`

2) `MANIFEST.yaml`

3) `instructions/`, `patterns/`, `anti-patterns/`

4) `checklists/`, `skills/`, `prompts/`, `templates/`

5) `overrides/`

6) `memory/` (the secret sauce)