Forem: Jim Zandueta

Stop Using Your Most Expensive AI Model to Stamp the Paperwork

Jim Zandueta — Mon, 11 May 2026 13:49:31 +0000

AI coding tools are incredible.

They are also starting to feel a bit like ordering room service at a five-star hotel.

You ask for "one small change," blink twice, and suddenly your token bill is wearing a bow tie.

That sounds dramatic, but if you use these tools every day, you know the feeling. Claude Code, OpenCode, Cursor, Copilot, all of it. We are living through this very odd moment where a half-formed thought can turn into a working patch before your coffee cools down. Things that used to take three browser tabs, two Stack Overflow answers, and one quiet crisis at the keyboard can now happen in a single conversation.

The awkward part is that they work.

So you use them constantly.

And once you use them constantly, the economics stop being theoretical.

Token limits. Session limits. Rate limits. Premium models. Long context windows. Repeated retries. Agents writing updates to other agents like they are defending dissertations nobody asked for.

After a while, every prompt had an imaginary CFO sitting next to it.

Are you sure you want to ask that question?

Could this be done by a cheaper model?

Did you really need frontier-model reasoning to rename a variable?

Annoying little guy.

Also, annoyingly, not wrong.

That started changing how I worked.

I asked fewer questions. I tried fewer weird ideas. I caught myself saving prompts for "real" work, which is a strange place to end up with a tool that is supposed to make development feel lighter.

I wanted to keep the magic of AI coding without treating every iteration like a small financial event. I wanted to refactor, experiment, throw things away, ask dumb questions, ask better questions, and generally behave like a developer without feeling like every prompt needed a purchase order.

The Problem Wasn't the Expensive Model

I don't think premium models are the villain.

They are expensive because they are good. Annoying, but fair.

If I am making an architecture decision, I want the big brain in the room. If I am doing security review, yes, please send the adult. If I am debugging something production-shaped that smells faintly of DNS, IAM, and regret, fine. Summon the oracle.

But updating docs?

Routing a task?

Scheduling implementation work?

Making a small mechanical change that is basically "move this thing over there and run the test"?

That probably does not need the most expensive model available.

That is how the paperwork metaphor got stuck in my head. Using a frontier model for every tiny task feels like asking your most senior engineer to staple documents. They can do it. They may do it beautifully. There may even be an elegant staple placement strategy. But financially, spiritually, and operationally, something has gone off the rails.

Quality was not the thing bothering me. Allocation was. We had started treating every AI task as if it needed the same level of reasoning, the same amount of context, and the same budget. Convenient, yes. Also lazy in a very expensive way.

The Open Model Detour

The other thing I could not ignore: cheaper and open-weight models had quietly become good.

Not "replace everything tomorrow" good.

Not "redesign my distributed system while I make lunch" good.

But absolutely "why am I paying premium rates for this README edit?" good.

The price differences can be silly. In some cases, you are not talking about 10% cheaper. You are talking about one or two orders of magnitude cheaper. That changes behavior. When every request feels expensive, you get cautious. You ask fewer questions. You experiment less. You stop doing those weird little exploratory loops where you learn things.

AI turns from a development partner into an emergency resource in a glass box.

Break only in case of billable disaster.

My first attempt at fixing this was not elegant. I patched Claude Code to point at a local Ollama server instead of Anthropic's API. It worked, which was both exciting and slightly cursed. I got decent uninterrupted work done, but it felt clanky. Like taping a jet engine to a bicycle and then insisting the bicycle had achieved flight.

That detour pushed me toward OpenCode, because OpenCode is model-agnostic. You can connect different providers and switch models without changing your whole workflow.

That mattered more than I expected, because model choice stopped feeling like a separate chore and started feeling like part of the workflow.

The Better Question

Once model switching was easy, I kept coming back to the same question: why is one model doing all the jobs?

Not because cheap models should do everything. That would be a different kind of mistake.

What started to make sense was using the right model for the right job, and not dragging unnecessary context into every call.

Some work is coordination. Some work is implementation. Some work is review. Some work is genuinely hard reasoning. Those should not all be priced, routed, or treated the same way.

You would not ask your most expensive lawyer to print the documents, book the meeting room, and staple the contract.

You want them involved when judgment matters. You do not need them guarding the printer tray.

AI models are not exactly lawyers, thank God, but the principle is similar.

Use expensive reasoning where expensive reasoning changes the outcome. Use cheaper models where the task is bounded, mechanical, or mostly coordination.

That split became the first useful rule of thumb.

Tier	Used For	Why It Helps
Cheap and fast	Routing, scheduling, bounded tasks	Keeps routine coordination inexpensive
Balanced	Everyday implementation and review	Preserves quality where most work happens
Premium	Deep architecture, hard problems, security escalation	Saves expensive reasoning for high-leverage moments

Spend the Big Brain Where It Matters

Cost is where the difference shows up first.

Not in the sad sense of "make it cheaper by making it worse."

Nobody wants a cheap system that creates expensive problems. That is not savings. That is deferred pain with better branding.

Spend money where it matters. Put premium models on judgment-heavy tasks. Put balanced models on normal implementation. Put cheap and fast models on bounded coordination work.

That is a much healthier pattern than sending everything through the same premium model and hoping the invoice develops mercy.

It also changes how you work. Lower marginal cost makes experimentation feel normal again. You ask the extra question. You test the weird idea. You let the machine do the boring cleanup. That matters, because good software work is often iterative and mildly messy before it becomes obvious.

Make the Agents Stop Writing Novellas

The second cost saving is funnier, because it is really about manners.

Agents talk too much.

Not to users. Users deserve clarity. I want the explanation. I want the reasoning. I want to know what changed and why.

I mean agents talking to other agents.

A typical AI handoff can be ridiculously verbose:

After carefully analyzing the implementation surface area, I have determined that the backend engineer should inspect the following files and consider the implications of the existing authentication flow...

Sir, this is a task handoff. Nobody asked for the director's commentary.

The user-facing explanation can stay clear. The machine-to-machine parts can be terse.

Something like:

Need backend fix. Files: X, Y. Run tests: Z. Risk: auth. Do not touch docs.

Beautiful.

Primitive.

Financially responsible.

The gimmick is funny, but the point is real: internal communication is not free. Every extra word passed between agents costs tokens. Every long summary adds context. Every polite essay burns budget without necessarily improving the outcome.

At some point, verbosity becomes a feature you are paying to remove.

Context Is Not Free

The cost part was obvious. The performance part snuck up on me.

Large AI conversations get heavy in a way that is hard to notice until you have lived inside one for a while. When one big agent does everything, it drags a huge amount of context around with it: requirements, file contents, previous decisions, failed attempts, summaries, side quests, emotional baggage, maybe a recipe for banana bread from three prompts ago.

That context has a cost.

It can slow things down. It can increase spend. It can also make the model less focused. Not always dramatically, but enough that you feel the drag.

The more irrelevant material in the context window, the more chances the model has to get distracted, overreach, or "helpfully" modify something nobody asked it to touch. We have all seen that moment where a small task becomes a surprise renovation.

The boring-but-effective version: give each role the context it needs, not the whole attic.

The planner gets planning context.

The frontend engineer gets frontend context.

The backend engineer gets backend context.

The reviewer gets the implementation summary and verification evidence.

We already know this from normal work: you do not invite the entire company into every meeting. At least, you should not. Some calendars are crimes.

Same idea here.

Smaller task-specific context usually means faster calls, lower cost, and better focus. It also makes the system easier to reason about. If something goes wrong, you can usually tell where it happened: design, planning, implementation, review, or escalation.

That is much better than staring at one giant chat transcript and wondering where the raccoon entered the ventilation system.

Process Keeps the Magic From Touching Production Unsupervised

Cost and speed are great.

But the thing that made this feel worth turning into a real workflow was control.

AI coding can feel magical, but magic is not a software delivery process. Magic is useful. Magic is fun. Magic should probably not have write access to production-adjacent files without an adult nearby.

A single agent can write a lot of code quickly. That is useful. It is also risky if there are no boundaries.

Sometimes the agent edits unrelated files.

Sometimes it skips tests.

Sometimes it solves the wrong problem confidently.

Sometimes it decides that your small UI tweak is the perfect moment to refactor authentication, redesign the database schema, and spiritually rebrand the company. Inspiring? Maybe. Requested? Absolutely not.

At that point, plain old software process starts looking less boring.

For substantial work, the flow should look more like this:

Yes, there is ceremony in that. I get it. Nobody wants every typo fix to become a government procurement process.

Tiny, safe tasks should have a fast path.

But for substantial work, I want the boring safeguards.

Before code is written, there is a design.

Before implementation starts, the user approves the plan.

Implementation tasks have file locks.

Sensitive areas like auth, payments, secrets, production config, and personal data trigger extra care.

Agents must provide verification evidence before calling work complete.

Review is a real phase, not a vibes-based victory lap.

Not to slow everything down. To stop AI from being confidently chaotic.

Because the problem with AI coding is not that it cannot produce code. It can produce lots of code. Buckets of code. Code with confidence. Code with explanations. Code that looks like it has somewhere important to be.

The hard part is making sure it produces the right code, in the right place, with the right review, for the right reason.

What This Turned Into

That is the shape of oowl: OpenCode Opinionated Workflow Layer.

Repo: https://github.com/jimzandueta/oowl

Docs: https://jimzandueta.github.io/oowl/docs/

The name is a mouthful, but the idea is not. It is an open-source workflow layer on top of OpenCode that treats AI coding less like one heroic chat session and more like a small engineering process.

Instead of one giant agent carrying the whole universe, work moves through specialized roles: dispatcher, architect, planner, implementation agents, reviewers, security escalation, low-cost workers for bounded tasks, premium agents when the problem is actually hard.

Basically, a small engineering team.

Except nobody asks to move standup to 4:30 and the backend engineer does not have opinions about espresso.

Not cheap models everywhere. More like: put the expensive thinking where it belongs, and keep the rest lean:

Model switching reduces cost by matching the model to the task.
Caveman-Lite reduces waste by compressing internal agent communication.
Smaller task-specific contexts improve speed and focus.
An opinionated SDLC process makes the workflow safer and more reliable.

The reason I care about this is that AI coding is moving from novelty to infrastructure.

The early question was:

Can AI write useful code?

The more useful question now is:

Can AI help ship software reliably, repeatedly, affordably, and safely?

That changes the shape of the work.

And honestly, that is where the conversation gets more interesting to me.

Model quality matters, obviously. Better models help. But once the models are useful enough, workflow quality starts to matter just as much.

The future of AI development probably is not one chat window with one all-powerful model doing everything. That is a useful demo, but it is a weird operating model.

Orchestration feels more durable.

Different agents. Different responsibilities. Different models. Clear handoffs. Compressed internal communication. Human approval where it actually matters.

That is the piece oowl is trying to explore.

Not perfect. Not universal. Definitely not the final form of anything. But useful enough that I wanted to put it out there.

Still magical.

Just with fewer surprise invoices.

And slightly more caveman.

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!

Forem: Jim Zandueta

Stop Using Your Most Expensive AI Model to Stamp the Paperwork

The Problem Wasn't the Expensive Model

The Open Model Detour

The Better Question

Spend the Big Brain Where It Matters

Make the Agents Stop Writing Novellas

Context Is Not Free

Process Keeps the Magic From Touching Production Unsupervised

What This Turned Into

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)