DEV Community: Jim Zandueta

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

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)