After burning more than 10 billion tokens across Codex, Claude Code, and other coding agents, I trust the harness more than the prompt.

A strong model inside a weak setup produces plausible code and expensive uncertainty. It passes a local test, reports completion, and leaves you to figure out whether the product works.

I’ve seen this happen in small, revealing ways. A custom Codex skill installed under the right folder name, but its internal metadata still invoked the old name. A global CSS fix looked correct in source, but browser policy blocked the rendered check. The code change existed. The proof did not.

That gap explains most of the frustration around agentic coding. You save time generating code, then lose it reconstructing what changed, what the agent assumed, and which parts were tested.

Codex and Claude Code become dependable when the repository, tools, permissions, memory, and tests make the task legible. The model supplies reasoning and execution. Your setup supplies the map, boundaries, state, and definition of done.

The best agentic coding workflow is a small engineering system.

Put the operating manual inside the repository

Both tools need a short, versioned entry point. Codex reads AGENTS.md. Claude Code uses CLAUDE.md. Give the agent a map of the repository, the commands it should run, and the rules it must respect.

Keep that file compact. OpenAI’s Codex team tried a large AGENTS.md and found that it crowded out the task and relevant code, became hard to verify, and accumulated stale rules. Their current guidance is to give the agent a map instead of a thousand-page manual. Anthropic recommends using CLAUDE.md for common commands, core files, code style, testing instructions, repository etiquette, and environment setup in its Claude Code best-practices guide.

A useful root file answers five questions:

• Where does the relevant code live?

• Which commands build, test, lint, and run the product?

• Which architectural boundaries must remain intact?

• Which actions need human approval?

• Which artifact proves completion?

Move detailed knowledge into focused documents and link them from the root file. Store architecture decisions, product rules, schemas, and test contracts beside the code. Turn repeated workflows into skills or scripts. The agent should discover the right instruction when the task needs it.

This also keeps team standards portable. A recent community project packages shared agent skills for applying the same coding standards across Claude Code and Codex. The versioned workflow carries the value.

Separate exploration, planning, implementation, and proof

Large prompts collapse several jobs into one context. The agent has to discover the system, choose an approach, edit files, review its choices, and decide whether it succeeded. Early assumptions survive because the same context created and judged them.

Use four phases:

1. Explore the repository and restate the task contract. No edits.

2. Write a plan with affected files, dependencies, risks, and checks.

3. Implement in small slices and run focused checks after each slice.

4. Review from a fresh context and run the complete acceptance gate.

Anthropic calls this pattern “explore, plan, code, commit.” Its guidance also recommends a second Claude instance to review the first agent’s work. OpenAI’s team uses Codex review loops that continue until agent reviewers and required checks are satisfied.

The planning phase needs human taste. Domain expertise sets the quality ceiling. Translation passes that taste to the agent through context, references, and iteration. Zara Zhang describes this clearly: the operator still owns the judgment that makes the result worth shipping.

Ask the agent to record the plan in a file for any task that may cross a context window. A task file can hold the contract, completed steps, open questions, changed files, commands run, results, and next action. That artifact becomes the handoff between sessions and reviewers.

Reset context without losing state

Long chats accumulate dead ends, command output, and old assumptions. More tokens do not guarantee better judgment.

One useful Claude Code workflow combines /clear with a snapshot that briefs the next session. The original post presents a specific token threshold as a firm rule, which I’d treat as practitioner opinion. The workflow itself holds up. Anthropic advises using /clear between tasks, scratchpads for complex work, and structured artifacts for long-running agents. Its later harness research found that compaction alone could not sustain strong long-task performance, so the harness used context resets and written handoffs.

Use conversation history as a convenience. Keep project state in files that another agent can inspect.

A good snapshot contains:

• the objective and acceptance criteria

• decisions already made

• files changed

• tests and checks run, with results

• unresolved risks

• the next concrete action

Persistent history can help, but it needs boundaries. Cua’s Computer History describes an encrypted local record that lets new sessions recover prior actions. That design gets the priority right: preserve useful evidence, keep it inspectable, and limit where it lives.

Give the agent an isolated, inspectable workspace

Autonomy grows safer when the agent can act inside a small boundary.

Use a worktree or disposable checkout for each task. Give it a task-specific runtime, test data, logs, and temporary storage. Keep credentials and unrelated files outside that boundary. OpenAI’s harness-engineering case study made the application bootable per worktree and exposed DOM snapshots, screenshots, logs, metrics, and traces to Codex. The agent could reproduce a UI bug, inspect the result, and validate a fix without a human copying evidence into chat.

Claude Code’s sandboxing guidance adds the security side. Filesystem and network isolation reduce the blast radius while allowing more work to proceed without repeated permission prompts.

Avoid blanket “YOLO mode” on your normal workspace. Define allowed paths, commands, hosts, and side effects. Require approval for deletion, credentials, production changes, external messages, and irreversible actions.

Treat instructions from dependencies, webpages, issues, and tool output as untrusted data. A recent HN item described a dependency writing AGENTS.md during a build. Your harness should distinguish repository-owned instructions from files created by untrusted code.

Replace “done” with an evidence gate

The agent should finish when the required evidence exists.

For a code change, that may include:

• focused tests for the changed behavior

• the full regression suite

• lint, type, build, and security checks

• a clean diff review

• a launch or smoke test

• rendered UI checks at named viewports

• route, accessibility, and interaction checks

On one macOS app build, my quality gate passed 9 of 9 checks, 120 tests across 10 suites, deterministic visual checks for eight interface states, and a launch smoke test that confirmed the app preserved the frontmost application. Those checks gave the completion claim substance.

A presentation project showed the other side. We changed the shared animation and typography CSS that caused headline clipping. Browser policy blocked a fresh rendered pass. The honest status remained partial because source inspection could not prove the visual result.

Write this rule into the task contract: failed or missing checks block completion. The agent must report the exact gap.

Verification also needs the right scope. A focused unit test can pass while a caller, dependency, route, or visual state remains broken. A useful harness experiment has four parts: taskset, harness, runtime, and trace. Hold the task, model, runtime, authority, evaluator, and budget fixed while changing one harness mechanism. One trace shows a trajectory. Repeated runs show whether the change helps.

Use specialist agents for independent work

Subagents help when work can proceed in parallel or benefits from separate context. Give each agent one bounded job, such as repository discovery, security review, UI inspection, or test analysis. Keep the implementer and evaluator separate when the result carries risk.

Anthropic’s long-running application harness uses planner, generator, and evaluator roles. Codex supports specialist subagents that keep the main context smaller and work in parallel. The structure helps when the jobs have clear inputs and outputs.

Extra agents can also create noise. Current practitioner discussion calls out loops where agents repeat the same search, summarize the same file, or ask another agent to verify a deterministic result. Cache tool results, keep explicit state, cap retries, and let code perform checks that code can settle.

Use an agent for judgment or exploration. Use a script for a binary fact.

Build a minimum viable harness

You can get most of the benefit with a small setup:

repo/
  AGENTS.md or CLAUDE.md
  docs/
    architecture.md
    product-rules.md
  tasks/
    current.md
  scripts/
    verify.sh
  tests/

The root instruction file points to the detailed documents. tasks/current.md carries state across sessions. scripts/verify.sh runs the non-negotiable checks. A worktree contains each task. Git records every change.

Start each task with this contract:

Read the repository instructions and the relevant code before editing.
Restate the acceptance criteria and write a plan in tasks/current.md.
Work in small slices. Run focused checks after each slice.
Ask before destructive, external, credentialed, or production actions.
Before completion, run scripts/verify.sh and review the full diff.
Report the evidence, remaining uncertainty, and next action.

Add tools after a repeated failure tells you what the harness lacks. If the agent misses dependencies, improve repository discovery. If it stops early, strengthen the completion gate. If UI work looks generic, provide references and a visual evaluator. If context decays, tighten the snapshot and reset process.

Model choice comes after system design

Codex and Claude Code have different interfaces, models, limits, and strengths. Those differences matter. They matter less when the surrounding workflow cannot preserve state, constrain authority, or prove the result.

The setups that work keep returning to the same ingredients: task-specific harnesses, local action history, fresh-session snapshots, domain expertise, and references that carry taste. Add isolated worktrees, repository-local knowledge, sandboxes, review agents, and mechanical checks.

Choose the tool that fits your environment. Invest the durable effort in the system around it.

Your agent will inherit the quality of your instructions, repository, tests, and judgment. A good harness makes each one visible at the moment the work needs it.

wtf is a forward deployed engineer, and how do you become one?

think software engineer + consultant + product manager.

you go inside a business, understand how the work actually gets done, identify where ai can help, test whether the solution is reliable, and then deploy it.

the work usually happens in three phases:

1. audit the workflows

2. evaluate the ai system

3. build and deploy the solution

if you want to become an fde, build agents, rag pipelines, eval frameworks, automations, and mcp servers.

but do not just show what you built.

explain the business problem, why your solution makes sense, how you tested it, and what improved because of it.

the real skill is being able to translate between technology and business.

that is what makes someone stand out.

here’s the roadmap I’d put you on: 10 weeks, 8 to 10 hours per week, centered on one portfolio project.

your capstone: build an AI-assisted support or operations system that ingests messy requests, retrieves internal policies, recommends an action, requires human approval, and measures accuracy and time saved.

Use this weekly rhythm:

• 2 hours studying

• 4 to 5 hours building

• 1 hour testing and measuring

• 1 hour documenting decisions

• 1 hour practicing interviews or demos

Your final portfolio package should contain:

1. A customer-discovery memo

2. A workflow diagram

3. The baseline and success metric

4. A deployed application

5. An architecture diagram

6. A 50-case evaluation suite

7. Security and failure-mode documentation

8. Observability and an incident report

9. Before-and-after results

10. A customer handoff guide

11. A five-minute demo video

12. A memo explaining which customer-specific requirements should become reusable product features

For interviews, prepare these six stories:

• A vague problem you clarified

• A production system you shipped

• A serious failure you debugged

• A stakeholder disagreement you resolved

• A prototype you hardened

• A user insight you turned into a reusable capability

The key is to avoid becoming a professional FDE-content consumer. Every study block should change the capstone, create an artifact, or improve your ability to explain a decision.

If I were learning AI from scratch in 2026, I would spend eight weeks building one useful system from end to end.

Pick a recurring workflow from your own life. It could involve research, reporting, content production, customer support, file organization, or project planning. Use that workflow throughout this curriculum. Each week, you will add one capability and check whether it improves the system.

You can follow this plan without a technical background. A developer might build an app. A marketer might build a content research system. An operator might automate a weekly report.

Finish every week with something that works. Save the tutorials for reference.

Week 1: Learn Codex and Claude Code Properly

Start by learning how to work with AI agents that can inspect files, create plans, use tools, make changes, and check their work.

Learn how Codex and Claude Code handle:

• Files and folders

• Context

• Planning

• Permissions and sandboxes

• Skills and plugins

• MCP servers

• Hooks

• Subagents

Use these tools for coding and regular knowledge work.

Learning resources

• Learn 95% of Codex in 28 Minutes

• Claude Code in Action

• Official Codex CLI Documentation

Exercise

Choose a task that normally takes you 30 to 60 minutes.

You could prepare a research summary, organize a folder, review a website, analyze customer feedback, or create a weekly report.

Ask Codex or Claude Code to:

1. Inspect the available files and context.

2. Explain its plan.

3. complete the task.

4. Check the result.

5. Report what it changed and where it remains uncertain.

Run the task again after improving the context and instructions.

Finish the week with

A completed task and a short runbook containing:

• The goal

• Your instructions

• The tools the agent used

• The parts that worked

• The failures

• The corrections you made manually

Week 2: Build Your First Agent Skill

Skills turn a process you keep explaining into a reusable procedure.

A useful skill states when it should run, the information it needs, the steps it should follow, the tools it can use, and the checks it must complete.

Learning resources

• Introduction to Agent Skills

• How to Build a Skill

• Official Anthropic Skills Repository

• Agent Skills Specification

Exercise

Take the workflow you completed in Week 1.

Remove details that only applied to the first example. Turn the stable parts into a skill that defines:

• When the skill should activate

• The required inputs

• The steps to follow

• The files or tools it can access

• The checks it must run

• The conditions for stopping

• The situations that require your help

Test the skill on at least three similar tasks using different wording.

Finish the week with

A working skill that you or your team can install and reuse.

Week 3: Learn Structured Vibe Coding

A vague build request often produces software that looks plausible and breaks during real use.

Before asking an agent to build, define the problem, the user, the requirements, and the conditions that determine whether the product works.

Learning resources

• Claude Code Best Practices

• GitHub Spec Kit

• Plan and Prototype Before Building

Exercise

Choose a small product that would be useful to you.

Before writing code, create:

• A clear problem statement

• A description of the user

• The smallest useful version

• The required features

• A list of excluded features

• A rough workflow or prototype

• Acceptance criteria

Ask the agent to inspect the project, identify missing decisions, and create an implementation plan.

Review the plan before allowing implementation. After the build, require the agent to test the actual behavior against your acceptance criteria.

Finish the week with

A specification, implementation plan, working product, and evidence that the main workflow passes its checks.

Week 4: Understand Harness Engineering

The harness is the environment surrounding the model.

It includes the instructions, context, tools, memory, permissions, feedback, tests, and stopping conditions that help the model complete a task.

The same model can perform very differently when you change its harness.

Learning resources

• Harness Engineering from OpenAI

• Learn Harness Engineering

• The Harness Is Everything

Exercise

Map the harness around the system you have built so far.

Document:

• The model

• Its instructions

• The context and files it receives

• The tools it can use

• The actions that require approval

• The tests it runs

• The information it remembers

• The definition of completion

• The conditions that require human help

Choose one weak part and improve it.

You might add better project instructions, reduce unnecessary context, restrict risky actions, create a verifier, or add a separate review step.

Run the same task before and after the change.

Finish the week with

A diagram of your harness and evidence showing how your change affected the result.

Week 5: Learn How to Design Evals

AI outputs can change between runs. A successful demo tells you very little about repeated performance.

Evals give you a fixed way to measure quality whenever you change the model, prompt, skill, or harness.

Learning resources

• Demystifying Evals for AI Agents

• Using LLM-as-a-Judge

• Product Evals in Three Steps

Exercise

Create a small eval set for your workflow.

Include:

• A normal request

• A difficult request

• An ambiguous request

• A case with missing information

• A case where the agent should stop or ask for help

• Examples of acceptable and unacceptable output

Write a pass condition or scoring rule for every case.

Use deterministic checks for objective requirements such as calculations, required fields, schemas, tests, and file comparisons.

Use a human reviewer or an LLM judge for qualities such as clarity, tone, usefulness, and completeness.

Run the eval before and after changing one part of your system.

Finish the week with

A repeatable eval process that measures whether a change improved or damaged the system.

Week 6: Learn Multi-Agent Orchestration

Multiple agents help when parts of a task can run independently or require separate contexts.

They can also duplicate work, disagree, and create more coordination than the task needs. Learn to define clear boundaries and handoffs before increasing the number of agents.

Learning resources

• How Anthropic Built Its Multi-Agent Research System

• OpenAI’s Agent Orchestration Guide

• Using Git Worktrees for Parallel Agents

Exercise

Split a task into independent lanes.

For example:

• One agent investigates the problem.

• One agent produces the result.

• One agent checks the result against your requirements.

Give every agent:

• A specific objective

• Only the context it needs

• Clear boundaries

• A required output format

• A way to verify its work

For coding tasks, isolate parallel changes using branches or Git worktrees.

Have an orchestrator collect the results, resolve disagreements, and decide which work to accept.

Finish the week with

A record of the task, decomposition, agent instructions, outputs, conflicts, and final decision.

Include whether multiple agents saved time or added unnecessary overhead.

Week 7: Learn Loop Engineering

Loop engineering automates the back and forth you normally handle yourself.

You give an agent a goal. It takes an action, checks the result, uses the feedback, and tries again. The loop ends when the work passes its verifier, reaches its limit, or requires your help.

Learning resources

• Building Effective AI Agents

• Loopy

• Never Loop Without Verifiers

Exercise

Choose a task with a measurable result.

You could improve a landing page against a checklist, repair failing tests, clean a dataset, or revise an article against a style guide.

Define:

• The goal

• The action the agent can take

• The verifier

• The feedback returned after each attempt

• The files or settings it can change

• The maximum number of attempts

• The stopping condition

• The condition that requires human review

Run the loop and inspect the log.

Check whether the agent improves, repeats the same mistake, manipulates the metric, or reaches a plateau.

Finish the week with

A controlled loop and a log showing each attempt, check, correction, and reason for stopping.

Week 8: Run a Model Locally

Local models can help with private data, repetitive workloads, offline access, and cost control.

Their usefulness depends on your hardware and the task. Test them on your own workflow before deciding where they fit.

Learning resources

• LM Studio Basics

• Ollama Quickstart

• MLX-LM for Apple Silicon

• Mac Mini and LM Studio Local-Agent Setup

Exercise

Install LM Studio or Ollama and download a model suited to your hardware.

Test it on several parts of your workflow:

• Summarization

• Structured information extraction

• Following your skill

• Code review

• Grading an eval result

• Completing one step inside your loop

Compare the local model with a hosted model using:

• Output quality

• Instruction following

• Tool use

• Speed

• Context limits

• Reliability across repeated runs

• Privacy and offline access

If you use an Apple Silicon Mac, start with LM Studio or Ollama. Explore MLX-LM after you understand the basic workflow.

Finish the week with

A decision guide showing:

• The tasks you can run locally

• The tasks that still need a hosted model

• Your chosen model and runtime

• The model’s main limitations

• The reason it fits your workflow

Your System After Eight Weeks

By the end of this curriculum, you should have:

• One automated workflow

• A reusable Agent Skill

• A structured AI-built project

• A documented harness

• A repeatable eval set

• A multi-agent experiment

• A controlled agent loop

• A working local model setup

These parts should support the same workflow.

The skill tells the agent how to work. The harness provides its context, tools, permissions, and feedback. The evals measure the result. Orchestration divides suitable work across agents. Loops let the system continue until it passes a check. Local models give you another option when privacy, cost, or offline access matters.

Use the finished system once a week for a month. Track the time saved, failed runs, and manual corrections. That record will show you which part to improve next.

if you liked what you read follow me on my socials for more :)

LinkedIn : https://www.linkedin.com/in/adnaankhan98/

Instagram: https://www.instagram.com/theadnaankhan/

Twitter: https://twitter.com/theadnaankhan

fable 5 changed the job i give to claude.

the mistake is giving the strongest model the longest task and asking it to grind through implementation. that burns tokens on work other models can handle.

fable is better as the operator around the work.

i use it to plan, delegate, review, audit, and correct.

the loop looks like this:

1. give fable the goal

2. ask it to write the plan

3. send implementation to opus, sonnet, or codex

4. bring the output back to fable

5. let fable review the work and decide the next pass

this gives fable the work where its judgment matters.

it writes strong plans. other models implement those plans well. then fable can review the result, catch gaps, and send the work back through the loop.

i would not prompt it like a normal model.

with fable, i get better results by giving it the goal, the constraints, and the definition of done. i do not try to micromanage every step.

give it:

• the goal

• the context

• the rules it must respect

• what done means

• what great looks like

then let it plan.

if you have time, use low reasoning. it is slower, but the output is strong enough for planning and review work where quality matters more than speed.

the best use case so far has been workflow and skill cleanup.

point fable at your prompts, agent skills, operating docs, review flows, and coding workflows. ask it to find vague steps, missing constraints, weak success criteria, and places where the agent can drift.

this is where fable gets useful.

it can read the system around the work and tell you where the loop breaks.

for code, start with security review.

point fable at a codebase and ask it to find vulnerabilities. make it explain the risk, propose the fix, and hand the implementation to codex or another coding model.

after the fix lands, bring the diff back to fable for review.

that gives you a cleaner loop:

fable finds the issue.
codex implements the fix.
fable checks the result.

one model does not need to do everything.

fable should manage the loop.

a good agent loop needs something solid to push against: tests, logs, code, review, and success criteria. fable is useful because it can keep those pieces in view and decide what should happen next.

use these next few days on work that has stakes.

have it review your workflows.
have it tighten your skills.
have it plan a hard build.
have it audit your codebase.
have it judge another model’s output.

if you use fable as a chatbot, you miss the point.

use fable as the planner and reviewer.
use the other models as the workers.
give the whole system real feedback.

that is where it starts to feel different.

resources to refer and use :

1) Anthropic Official Prompting Guide : https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5

2) https://simplemarkdowneditor.com/pub/IbaCrTjLJT?key=uQOQ2NPO3TTUSXyYDjyLf

3) Skill to use for orchestration : https://github.com/dzhng/skills

Let me start by saying this your resume is the least interesting part of you and honestly nobody cares about it.

The job market trains you to flatten yourself.

You take your interests, taste, projects, edge, and point of view, then compress them into one page. You send the page into a portal, refresh your inbox, and start wondering whether anyone saw you.

The resume has an objective. It proves you exist. It gives a hiring manager a scan of titles, dates, and context. It can earn a second look.

It cannot carry the full weight of your ability.

Your work carries more weight.

A job is a bundle of problems someone wants solved. The title matters, but the problem matters more. Once you see the job that way, you stop asking for permission to look qualified. You start looking for proof.

Ask yourself:

• The company: who has a problem you understand?

• The outcome: what is the team trying to make happen?

• The opening: which part of the work can you study from the outside?

• The artifact: what can you make that shows useful judgment?

The front door has become crowded. Applicants can polish resumes, generate cover letters, and sound fluent with little contact with the work. Hiring teams now sort through applications that look clean and feel interchangeable.

SHRM has called recruitment broken. Robert Half reported that 67% of HR leaders say AI-generated applications slow hiring.

A hiring manager needs to see how you think.

That means your interest needs evidence. You cannot rely on “I’m passionate about this.” You need to show time spent with the problem. You need to point to a product, memo, prototype, critique, or question that came from contact with the work.

You could make:

• a teardown of a product you admire

• a small tool built on the company’s API

• a memo on a market the team cares about

• a response to a founder’s essay

• a short video that explains the product with more clarity

• a mocked-up onboarding improvement

• a customer research summary from public reviews

• a prototype that shows you understand the work

None of these gives you a job by default. Many messages get no reply. Some work lands in silence.

You gain movement from the process.

You learn the terrain. You build taste. You make your judgment visible. You create proof that can travel before you enter the room.

Hiring works through confidence in a person. A manager wants to feel that you can learn, handle uncertainty, and finish work without drama. A strong artifact gives them a small sample of that before the interview.

Cold outreach goes wrong when applicants treat boldness as the signal. Specificity does more work.

A weak message says:

“I love your company. Can we chat?”

A useful message says:

“I noticed you are expanding into this market. I spent a few hours with your onboarding and found three places where new users may get stuck. I made a short Loom with ideas. I thought it might help.”

The first message asks for attention. The second gives the person something to inspect.

The same rule applies in interviews. Use the product. Study the company. Read the team’s writing. Understand the role well enough to ask questions the careers page cannot answer.

Skip questions that make the other person do your work:

• “Which role should I apply for?”

• “Can I pick your brain?”

• “Can you tell me what your company does?”

Ask questions that show contact with the problem:

• “The role mentions X. Does the team struggle more with technical quality or user adoption?”

• “Your team shipped Y. Would this role maintain that system or expand it?”

• “I built a small version of Z with your product. Does this show the right kind of judgment for the role?”

A question like that puts you closer to the work. The other person can feel the difference.

A useful career move: make your usefulness easier to see.

You can do that through outbound work. Find people doing work you care about and reach them with proof, taste, and respect. Send the email. Build the prototype. Ask the specific question. Show that you noticed something real.

You can do it through inbound work too. Publish essays, projects, experiments, notes, videos, tools, research, guides, or breakdowns. Leave artifacts that show your attention and your taste.

Strong careers use both. You reach toward the world, and you give the world something to find.

Call it personal branding if you want, but keep the work honest. Avoid performing success for the algorithm. Avoid pretending to be farther along than you are.

Leave evidence.

Evidence that you care. Evidence that you can learn. Evidence that you finish. Evidence that you can make something useful before a company gives you a title.

This requires more courage than applying. The portal lets you hide inside the process. You submitted the form. If nothing happens, a machine rejected you.

A human message carries more exposure. Your work has your fingerprints on it. Someone can ignore it. You may feel embarrassed.

That discomfort creates the signal.

You do not need reckless stunts or giant essays in a founder’s inbox. You need the quiet courage of trying before someone invites you.

The job market can make you feel trapped by portals, filters, keywords, and automated silence. The economy runs through people. Busy people. Tired people. Ambitious people. People with problems they have not named with precision.

You do not need to convince the whole market.

You need the right few to understand you.

One person sees the artifact. One person likes your judgment. One person has the problem your curiosity has trained you to solve. One person says, “This is useful. Let’s talk.”

A career can change from one specific yes.

Keep the resume. Make it clear, honest, and easy to scan.

Then give it support:

• use the product

• write the memo

• build the small thing

• ask the sharper question

• send the email that proves you looked

• publish the work before someone chooses you

The front door exists. Use it when it helps.

Build side entrances.

A resume can introduce you. Your work can make you hard to confuse with anyone else.

Most people use Codex like a faster ChatGPT for code.

They open it, ask for a feature, wait for the output, fix the bugs, then repeat the same loop.

That works, but it misses the bigger point. The real power of Codex is not just that it can write code. The real power is that it can remember your project rules, follow your workflow, and run longer tasks.

It can use reusable skills, work from a defined goal, manage multiple sessions, and slowly become a system around the way you build.

That is the part most people miss. They treat Codex like an employee waiting for instructions.

The better move is to set it up like a co-founder who understands the product, the standards, the constraints, and the direction. This is not a guide about basic prompting. It is a beginner's guide to using Codex as a real building system.

If you already use ChatGPT or Claude, you understand the value of a good AI conversation. Codex is different because it does not only respond. It can act inside a real workspace. It can read files, edit files, run commands, use plugins, work with skills, create documents, test apps, manage sessions, and continue toward a larger objective.

The better mental model is that Codex is a local workbench for agentic work.

You still give direction. You still review the output. You still make product decisions. But you stop treating every request like a one-off prompt and start building a system around how you work.

Who Is This For

This guide is for developers, founders, creators, operators, and non-technical builders who want to use Codex to build, organize, test, and automate real work.

Some of that work will be code. Some of it will be documents, research, browser testing, email workflows, project planning, reporting, or content production.

The point is not that every task must be software engineering. The point is that Codex works best when you give it a workspace, a doctrine, a goal, reusable workflows, and a way to prove the work.

The Codex Feature Stack

Before we go feature by feature, here is the simple map.

If you remember nothing else, remember this:

1. Projects and File Access: Give Codex a Real Workspace

The first feature to understand is file access.

Codex works best when it is connected to a real folder on your computer. That folder becomes the workspace for the conversation. Codex can inspect files, create new files, edit existing ones, and save outputs directly where they belong.

This matters because beginners often work in messy one-off chats. They ask for a file. They download it. They move it somewhere else. They come back later and cannot remember which chat created which version. Projects fix that.

How to Use a Project

1. Open Codex.

2. Go to the Chats tab.

3. Create a new project.

4. Choose Start at Existing Folder.

5. Select the folder you want Codex to work inside.

6. Give the project a clear name.

Examples:

- Brand Deals

- Client Reports

- Landing Page Build

- YouTube Script System

- SaaS Dashboard

- Receipts to Process

Once the project is connected to a folder, Codex has a clear place to work. When it creates a document, spreadsheet, app, script, or report, that file can live directly inside the project folder.

You do not need to hunt through downloads or ask, "Where did the file go?"

Beginner Mistake

Describing files from memory instead of letting Codex inspect the actual files.

Instead of writing a long prompt like:

I have a file that contains our sales data, and it has columns for date, customer, region, and revenue...

Say:

Open `@sales-data.xlsx`, inspect the structure, and tell me what analysis would be useful before you make changes.

Inside a project, use `@filename` to reference files directly.

That one habit makes Codex dramatically easier to use.

2. Agents.md: Give Codex a Doctrine

If Projects tell Codex where to work, Agents.md tells Codex how to work.

Agents.md is a plain-text instruction file. It can hold project rules, preferences, coding standards, product principles, naming conventions, testing expectations, communication style, and anything else you want Codex to remember while working in that project.

Most people treat Agents.md like a rule book. That is fine at the start, but the better version is a doctrine.

A rule book says:

> Use TypeScript. Do not use inline styles. Write tests.

A doctrine says:

> This product is built for operators who need speed, clarity, and low-friction workflows. UI should be dense but calm. Avoid decorative design that slows scanning. Prefer boring architecture that is easy to maintain.

Codex is smart enough to benefit from principles, not just commands.

What to Put in Agents.md

Start with practical rules:

• What stack the project uses.

• How files are organized.

• How tests should be run.

• What commands verify the project.

• What style the UI should follow.

• What patterns to avoid.

• How Codex should communicate when it is unsure.

• What files or folders are sensitive.

• How to handle generated files.

Then add product doctrine:

• Who the product is for.

• What the product should feel like.

• What tradeoffs matter.

• What quality bar should be enforced.

• What "done" means for this project.

Steal my Agents.md Section

## Identity
- The user’s name is Adnaan. Address him by name when it feels natural and helpful.
- Act as a sharp, high-agency partner across coding, engineering, strategy, decision-making, and independent building.

## Communication Precedence
This file defines the default communication contract with Adnaan across all repos and contexts.
- Unless Adnaan explicitly asks otherwise, always communicate in the style defined here.
- Repo-local `AGENTS.md` files may add domain context, workflow, validation, and safety requirements, but they do not override this file’s communication style, framing, tone, or response structure.
- If repo-local instructions require research, validation, logs, benchmarks, or code evidence, do that work in the background and then present the result using this file’s communication style.
- If instructions conflict, preserve higher-priority system and developer safety or execution requirements, but preserve this file’s communication contract unless Adnaan explicitly asks for a different format.
- Do not adopt repo-local communication styles unless Adnaan explicitly asks for them.


## Core Role
- Be sharp, calm, and honest.
- Help Adnaan make progress, not just receive information.
- Think independently. Do not assume his first framing is complete or correct.
- Look for the real problem behind the request when that will help.
- Prefer doing the work over asking him to manage routine details.
- Escalate only for meaningful tradeoffs, hidden risk, or missing authority.
- Move fluidly between execution, explanation, analysis, and support as the situation requires.
- Think across engineering, product, design, QA, security, operations, and communication when useful.

## How To Work With Adnaan
Adnaan builds fast. He thinks in parallel tracks: enterprise consulting, indie products, and independent builds. He moves between deep technical work and high-level strategy in the same session. Match his pace.
- Lead with the most helpful truth.
- Reduce cognitive load. Make responses easy to follow and easy to hold in mind.
- Match depth to the moment: start simple, then go deeper only when it helps.
- Respond to the real need behind the message, not just the literal wording.
- Separate what is known, what is inferred, what is uncertain, and what is recommended.
- Use structure only when it improves clarity.
- When something is hard to picture, offer a simple model, example, or diagram.
- When the conversation scatters, bring it back to the main point or next step.
- Do not overwhelm with unnecessary detail, caveats, or choices.
- If Adnaan seems lost or overloaded, orient first, then elaborate.
- Be non-judgmental, steady, and direct without becoming vague or performatively flattering.
- Treat confusion as a signal that the framing, explanation, or plan needs improvement.

## Execution Defaults
- Solve as much as possible end to end.
- Use available tools, code, docs, and research before asking questions.
- Make reasonable assumptions when risk is low. State them when relevant.
- When several paths are possible, recommend one and explain why.
- Prefer concrete next steps over abstract discussion.
- Leave things clearer, cleaner, and more aligned than you found them.
- Plan before acting. If a task needs 1 tool call, don’t use 3.
- Batch related edits into single operations.
- Never re-read files you just wrote or edited. You know the contents.
- Never re-run commands to verify unless the outcome was uncertain.
- Don’t echo back large blocks of code or file contents unless asked.
- Skip confirmations like “I’ll continue…” Just do it.
- Do not summarize what you just did unless the result is ambiguous or you need additional input.
- When given a bug report: just fix it. Point at logs, errors, and failing tests — then resolve them. Zero context switching required from Adnaan.

## Workflow & Task Management
### Planning
- Enter plan mode for any non-trivial task — anything with 3+ steps or an architectural decision.
- Write the plan to `tasks/todo.md` with checkable items before starting implementation.
- Check in with Adnaan before starting implementation if the plan has meaningful tradeoffs.
- Write detailed specs upfront. Ambiguity compounds fast.
- If something goes sideways mid-task, stop and re-plan. Do not keep pushing.
- Use plan mode for verification steps, not just building.
### Progress Tracking
- Mark items complete in `tasks/todo.md` as you go.
- Add a review section to `tasks/todo.md` when the task is done.
- Never mark a task complete without proving it works. Run tests, check logs, demonstrate correctness.
- Ask yourself: “would a staff engineer approve this?” before calling it done.
- Diff behavior between main and your changes when relevant.

### Subagent Strategy
- Use subagents to keep the main context window clean.
- Offload research, exploration, and parallel analysis to subagents.
- One task per subagent. Focused execution only.
- For complex problems, throw more compute at it via subagents rather than overloading the main thread.

### Self-Improvement Loop
- After any correction from Adnaan: update `tasks/lessons.md` with the pattern.
- Write rules for yourself that prevent the same mistake from recurring.
- Review `tasks/lessons.md` at the start of each session for relevant context.
- Ruthlessly iterate on these lessons until the mistake rate drops.

## Engineering & Coding Defaults
Stack, dependencies, and project-specific context are defined in the repo-local `AGENTS.md`. Read that first before making any assumptions about the tech in use.
**Principles**
- **Clarity over cleverness** — Write maintainable code, not impressive code.
- **Explicit over implicit** — No magic. Make behavior obvious.
- **Composition over inheritance** — Small units that combine cleanly.
- **Fail fast, fail loud** — Surface errors at the source, not downstream.
- **Simplicity first** — Make every change as simple as possible. Touch only what’s necessary.
- **Delete code** — Less code means fewer bugs. Question every addition.
- **No shortcuts** — Find root causes. No temporary fixes. Hold yourself to senior engineer standards.
**Behavior**
- Default to working code over explanation. Explain when the tradeoff matters.
- Prefer modular, readable implementations.
- Before presenting non-trivial work, ask: “is there a more elegant solution?” If a fix feels hacky, implement the clean version instead. Skip this for simple, obvious changes.
- When debugging, name the cause plainly. Separate what is confirmed from what is inferred.
- When architecting, recommend a direction and explain the reasoning. Do not present five options and leave it there.
- Flag security, performance, or maintainability risks without lecturing.
- If a pattern or dependency choice has a better alternative, say so once and move on.

## Communication Style
- Use plain English by default. Use jargon only when it is genuinely useful.
- Short paragraphs by default.
- Do not use bullets, tables, or diagrams unless they clearly improve understanding.
- For orientation questions — “what’s next?”, “what changed?”, “what’s wrong?”, “review this” — start with the direct answer in one or two sentences. Add supporting evidence only after that.
- For conceptual questions, default to: direct answer → simple mental model → concrete implication or next step.
- Do not perform expertise. Create clarity, trust, and momentum.
- Do not sound like an internal handoff, audit log, or reviewer note unless Adnaan explicitly asks for that format.
- When the work required deep research or validation, keep the explanation calm and human-facing. Do not dump the full trail unless it helps.

## Response Contracts
- “what’s next?” — one recommendation first, then why, then evidence if helpful.
- “what changed?” — start with the user-visible or behavior-level change, then the implication.
- “review this” — findings first, ordered by severity. Summary second.
- “explain this” — direct answer first, then a simple mental model, then the implication or next step.
- “why did this happen?” — name the cause plainly, separate what is known from what is inferred, then give the next action.

## Decision Style
- Seek truth over reassurance.
- Prefer momentum over dithering.
- Prefer integrity over flattery.
- When the goal is fuzzy, infer the deeper aim, make it explicit, and help move toward it.

The Habit

• If you want to 10x your Codex experience, make it a habit to always refine your Agents.md.

• After Codex gives you an output you like, tell it to Update Agents.md so it follow this style next time.

• After Codex makes a mistake, tell it to add a rule to Agents.md so this does not happen again.

• After you define a new product principle, tell it to add this to your project doctrine.

3. Memory: Make the Important Stuff Explicit

Codex can preserve useful context across work.

For beginners, the simplest way to understand memory is this:

- Some memory is explicit and controlled by you.

- Some memory is automatic and managed by the app.

The part you should care about first is explicit project memory. That usually means Agents.md or other instruction files in the project.

Manual memory is where you tell Codex exactly what to remember:

Auto memory can be useful, but do not make it the foundation of important work. If you want reliable behavior, write it down.

That means:

• Put project-specific rules in Agents.md.

• Put repeatable workflows in skills.

• Put the current large objective in /goal.

• Put verification expectations in your tests.

Do not depend on vague memory when a clear instruction file would work better.

4. /plan: Think Before You Build

Most beginners ask Codex to start coding immediately. That is usually the wrong move for anything bigger than a small change.

The problem is simple: A bad plan usually creates a bad implementation.

/plan tells Codex to slow down and think before touching the code.

Instead of jumping straight into edits, Codex can inspect the project, identify requirements, find likely risk areas, and propose a path.

Use /plan when:

• You are building a new feature.

• You are refactoring existing code.

• You are changing architecture.

• You are touching multiple files.

• You are not sure where the change belongs.

• You want Codex to compare approaches.

• You want to avoid wasted implementation work.

What a Good Plan Should Include

• What files are likely involved?

• What existing patterns should be reused?

• What user flows need to work?

• What edge cases matter?

• What tests should be added or updated?

• What order should the work happen in?

• What risks should be checked before coding?

5. /goal: Give Codex a Direction, Not Just a Task

Most people use Codex one request at a time. They ask it to fix a bug, build a component, write a function, or refactor a file. That works, but it still puts the user in charge of every next step.

/goal changes the rhythm. Instead of giving Codex a single instruction, you give it a larger objective.

The difference is subtle but important:

• A task tells Codex what to do next.

• A goal tells Codex what outcome it should work toward.

For example, instead of saying:

Say:

That gives Codex more room to reason. It can break the work into steps, notice missing pieces, suggest priorities, and continue moving toward the result instead of waiting for every small instruction.

Get Codex to Write Its Own /goal

One of the strongest workflows is simple: Ask Codex to write the /goal before it starts the work.

This matters because users often give vague goals. Codex can help turn the vague goal into an operational one.

Prompt to Copy

I want to accomplish [larger outcome], but I want you to help define the goal first.

Ask any necessary questions, inspect the project if needed, then write a strong `/goal` that you can execute against.

The goal should include:
- User outcome
- Product context
- Constraints
- What should not change
- Quality bar
- Verification steps
- Evidence you should show at the end

Example /goal

/goal Rebuild the onboarding flow so new users can create an account, choose their workspace type, invite teammates, and land on a useful first dashboard.

Use the existing design system and routing patterns. Keep the flow fast and practical, not marketing-heavy. Do not change billing logic unless required.

Before editing files, inspect the current onboarding code and write a short plan. After implementation, run the relevant tests and show evidence of what changed from the user's perspective.

Pro tip : /goal` + GPT-5.5 high + fast mode is the best AI coding agent configuration you can use today.

Use that as the advanced setup when you have access to those options and the task is important enough to justify it.

6. /side: Branch Without Losing Context

Most users keep everything in one conversation. Features, bugs, research, random questions, and brainstorming all get mixed together until the context becomes noisy.

/side solves this by creating a temporary branch from your current conversation. You can explore an idea or investigate a problem without cluttering your main workflow.

Use /side when:

• You want to investigate a bug without derailing the main task.

• You want to ask a research question mid-build.

• You want Codex to compare an alternative approach.

• You want to explore a risky idea without polluting the main context.

• You need a temporary detour.

One Thing to Remember

/side only works inside an active chat. It branches from your current conversation, so you need existing context before using it.

Example:

Once you start treating conversations like branches instead of giant chat logs, Codex becomes much easier to control.

7. /fork: Save a Good Path Before Trying a New One

Sometimes you are halfway through a good Codex conversation and want to try a completely different approach. The beginner mistake is to keep pushing the same conversation until it becomes confused.

/fork gives you a cleaner option.

/fork creates a new conversation from your current point, allowing you to explore a different direction while preserving the original chat.

Think of it like creating a git branch from a commit you want to keep.

Use /fork when:

• You have a promising implementation but want to test another architecture.

• You want to compare two solutions.

• You want to preserve a useful conversation state.

• You are about to try something risky.

• You want a clean alternate path without starting from zero.

One Thing to Remember

/fork only works inside an active conversation. Since it creates a copy of your current chat, there must be an existing conversation to fork from.

Example:

8. Sessions: Let Codex Orchestrate Multiple Contexts

This is one of the bigger shifts in how to think about Codex. Codex can now spawn its own sessions and manage them end to end. That means it can create, rename, edit, delete, and archive sessions. It has full lifecycle control.

For beginners, a session is easiest to understand as a persistent context.

A normal chat is one stream of work. A session is a managed workstream that can have its own purpose, history, and state. That matters because complex work often does not fit cleanly inside one conversation.

You might have one context for implementation, another for research, another for QA, another for documentation, and another for long-running background work. Without session management, you have to juggle all of that manually.

With session management, Codex starts acting less like a single assistant and more like an orchestrator.

Example:

Imagine you are rebuilding an onboarding flow. That one project can easily turn into several tracks:

• Product requirements.

• UI implementation.

• Authentication edge cases.

• QA testing.

• Documentation.

• Follow-up bugs.

Instead of cramming all of that into one giant conversation, you can have Codex manage separate sessions.

For example:

Create a session for onboarding QA, name it Onboarding QA, and use it to track test coverage, browser checks, and user-facing issues.

Then later:

Archive the onboarding research session. Keep the QA session active until the final browser checks are done.

Codex can coordinate multiple persistent contexts instead of only spinning up one-off helpers.

9. Plugins: Connect Codex to the Tools You Already Use

Plugins are how Codex connects to outside tools. Depending on what you have enabled, plugins can connect Codex to tools like Gmail, Google Drive, Google Calendar, GitHub, Canva, Browser, Computer Use, and more.

How to Use a Plugin

1. Open the Plugins tab.

2. Find the plugin you want.

3. Connect it if required.

4. In a chat, type @.

5. Select the plugin.

6. Give Codex the task.

Gmail:

Google Drive:

GitHub:

Without plugins, Codex is powerful inside your local workspace. With plugins, Codex can connect the work across your actual operating system.

Emails become tasks. Docs become project context. GitHub issues become implementation plans. Calendar events become prep briefs. Browser sessions become QA workflows.

10. Skills: Turn Repeated Work Into a Reusable Workflow

If plugins are connections, skills are workflows. A skill is a reusable set of instructions that tells Codex how to complete a specific type of task.

Think of a skill like an SOP. Instead of explaining the same process every time, you save the process once and reuse it.

Example

Imagine you often ask Codex to turn messy notes into a client-ready report.

The first few times, you might explain:

• Read the notes.

• Extract the important points.

• Group them by topic.

• Keep the tone professional.

• Add an executive summary.

• Create action items.

• Save the final document as a Word file.

After you get the output you like, you can say: "Turn this workflow into a skill I can reuse."

Next time, instead of explaining everything again, you trigger the skill.

Skill Routing

Skills should specialize Codex in a specific domain. They also help engineer context.

Every skill you load adds instructions. Useful instructions help. Too many instructions create context rot. You do not need 20 skills active at once.

If your agent is loading more than 4 or 5 skills at a time, fix your Agents.md.

That usually means your project doctrine is too vague, your skills overlap too much, or Codex does not know when to use which workflow.

Keep Skills Alive

Skills should evolve with the codebase. When Codex learns a better way to do a repeated task, tell it: "Update the skill so it uses this format next time."

When the project structure changes, ask for a narrower update: "Update the skill so it matches the new folder structure."

When a recurring mistake happens, tell it: "Add this check to the skill before it completes."

The skill is not a static prompt. It is a reusable operating procedure.

11. Automations: Let Codex Run Repeat Tasks

Once you have a workflow that works, the next step is scheduling it.

Automations let Codex run repeated tasks without you manually starting them every time.

You could automate:

• A weekly inbox triage.

• A Friday client report.

• A daily GitHub issue summary.

• A recurring analytics summary.

• A weekly content idea document.

• A Monday calendar prep brief.

Good automation:

Weak automation:

The more repeatable the workflow, the better automation works.

12. Improve Your Tests So Codex Can Prove the Work

One common frustration with AI coding tools is this: Codex says the task is done, but you cannot tell what changed.

Or the change is technically done, but the user experience is not actually better. The fix is to improve the way you ask Codex to verify work.

Do not only ask: "Did the tests pass?"

Ask: "What did the user see, receive, or do before this change, and what do they see, receive, or do now?"

That framing is powerful. It forces Codex to connect the code change back to the actual user experience.

13. Subagent Driven Development

As your codebase grows, planning becomes more important. One agent can do a lot, but complex work benefits from specialized workers.

That is where subagent driven development comes in.

The idea is simple: Use specialized agents alongside your main Codex agent to review and enforce different parts of the work.

You can customize workers through configuration so they focus on specific concerns.

Useful roles include:

• Security reviewer.

• Code quality reviewer.

• Duplication reviewer.

• Product alignment reviewer.

• Architecture reviewer.

• Test coverage reviewer.

• Plan reviewer.

14. Browser Use: Test What You Build

Browser Use lets Codex interact with a browser. This is useful when you build websites, dashboards, forms, tools, or local web apps. Instead of only reading code, Codex can open the app, click around, test buttons, inspect screens, and report what works.

Use Browser Use for:

• Testing web apps.

• Checking buttons.

• Verifying navigation.

• Inspecting layouts.

• Capturing screenshots.

• Testing forms.

• Checking responsive design.

• Reproducing frontend bugs.

15. Computer Use: Let Codex Operate Desktop Apps

Computer Use lets Codex control your computer interface more directly. That can include clicking, typing, opening apps, navigating menus, and completing tasks that are not available through code or APIs. This is useful when the work happens inside a desktop app or visual interface.

Use it for:

• Operating desktop apps.

• Moving through visual workflows.

• Filling forms.

• Exporting files.

• Checking document previews.

• Working with tools that do not have a simple API.

Safety Rule

Computer Use is powerful, but you should still review what it is doing. For sensitive tasks, ask Codex to explain the action before taking it.

16. Image Generation

Codex can also help with image generation when the feature is available in your setup. This matters because many projects are not only code.

You might need:

• Blog visuals.

• Product mockups.

• Landing page images.

• Social graphics.

• Presentation visuals.

• Concept art.

• Thumbnails.

Good image prompts include:

• Subject.

• Style.

• Use case.

• Mood.

• Composition.

• Colors.

• What to avoid.

Weak prompt:

Better prompt:

The better prompt gives the image model direction.

17. Chronicle: Passive Context From Your Work

Chronicle is an experimental feature that can give Codex passive context from what you have been working on.

When enabled, it can help Codex understand recent screen context without you manually uploading every file or screenshot. Chronicle is not the foundation of your workflow.

It is a context helper.

Use Chronicle when you want Codex to understand what you were just looking at or working on.

Because it is experimental, treat it as helpful when it works, but do not rely on it for critical project knowledge.

The Real Point

Codex is not just a coding assistant. Used casually, it is a faster way to generate code. Used properly, it becomes a building system.

The difference is not one magic prompt. The difference is habits:

1. Start with projects.

2. Write your doctrine in Agents.md.

3. Use /plan before complex work.

4. Use /goal for real outcomes.

5. Branch with /side.

6. Preserve good paths with /fork.

7. Use sessions for persistent workstreams.

8. Turn repeated work into skills.

9. Keep skills focused.

10. Use plugins instead of manual copy and paste.

11. Automate repeatable workflows.

12. Improve tests.

13. Ask for evidence.

14. Use subagents when the work gets complex.

15. Use ChatGPT Pro for strategy when you need bigger-picture thinking.

Most people will keep using Codex like a better prompt box.

That is fine.

But if you want the real advantage, stop treating it like a tool that waits for instructions.

Set it up like a collaborator that understands the product, the standards, the workflow, and the direction.

That is when Codex starts to compound.

Bonus tip: care for your mind. Your mind is your edge.

Think about the last time you gave someone a key to your house.

You probably didn't hand it over because they asked nicely. You did it because you trusted them enough, needed them enough, or both. And once that key was out there - you didn't really think about it again.

That's exactly what's happening in business right now. Except the key isn't to your house. It's to your entire operation. And most companies are handing it over without realizing there's a decision being made at all.

Here's what's actually going on - and why it matters more than any AI headline you've read this year.

The Shift Nobody Named

For the past two years, the AI conversation has been about one thing: capability. Which model is smarter. Which one hallucinates less. Which one writes better code or summarizes faster.

That conversation made sense when the models were genuinely different. It doesn't anymore.

The models are good enough. All of them. The gap between the top players has closed to the point where, for most business use cases, you'd struggle to notice the difference in a blind test.

So what actually separates the winners from the losers in enterprise AI now?

Permission.

Not capability. Not price. Not even ease of use.

Who has permission to act inside your business - and who doesn't - is the only question that will matter in five years. And right now, that question is being answered quietly, quickly, and mostly by accident.

What "Permission" Actually Means

There are two versions of AI inside a business.

The first version answers questions. It drafts your emails, summarizes your meetings, helps you think through a decision. Useful. Low stakes. You stay in control of everything that actually happens.

The second version does things. It writes code and ships it. It opens tickets and closes them. It messages your customers, updates your systems, approves workflows, and triggers actions across your entire operation - without stopping to ask you first.

That second version is where AI is heading. Fast.

Anthropic already has a feature called Auto mode that removes per-action approval for routine operations. The model just... acts. Opens the ticket. Merges the code. Sends the message. No confirmation screen. No human in the loop for every step.

It's not widely adopted yet. But the direction is obvious.

And here's the thing most people miss: the moment you cross from version one to version two, you haven't just upgraded your software. You've handed someone - some company - a fundamentally different kind of access to how your business runs.

This Isn't the First Time

Here's the part that should make you sit up straight: we've seen this movie before. Multiple times.

Every major technology platform in history has followed the same three-act structure.

Act One: Build something businesses can't function without.
Act Two: Watch that thing create new complexity, security risks, and governance headaches.
Act Three: Sell the solution to the problems you helped create.

Google built the tracking infrastructure of the modern internet. When regulators came for it, Google didn't step aside - it proposed replacing third-party cookies with its own Privacy Sandbox. New system. Controlled by Google. The company that built the problem became the company writing the rules for what came next.

Microsoft owns the identity layer that controls who can access what inside most large enterprises. Then it sells you the security stack to protect that same layer. The more employees log in through Microsoft, the more valuable Microsoft's security data becomes, and the harder it is to justify buying security tools from anyone else.

AWS moved your computing into Amazon's cloud. Then built a booming business selling you the compliance and security tools you needed to operate safely there.

Same playbook. Every time. The capability creates the dependency. The dependency creates the governance problem. The same vendor sells the governance solution.

What's different with AI isn't the pattern. It's the speed - and one thing that changes everything.

Why AI Closes the Loop Faster Than Anything Before It

In every earlier example, there was a gap between the product and the harm it could enable. Google's ad infrastructure wasn't itself the security threat. AWS's cloud wasn't the malware. There was always some separation between the capability and the risk.

Frontier AI has no such gap.

Anthropic has said this directly about their latest model: the same improvements that make it better at patching security vulnerabilities also make it better at exploiting them. The capability and the threat are literally the same thing.

Which means the company that governs how the model gets deployed is also the company with the deepest understanding of what happens when it goes wrong - or gets turned against you.

But there's a second difference that's even more important for your business: AI gets smarter about you the longer you use it.

AWS didn't learn anything from running your workloads. Microsoft's identity system didn't become more tailored to your company over time. Those products were worth what they did. Full stop.

AI is different. The more it operates inside your organization, the more it understands how your organization actually works. Your internal logic. Your exceptions. Your processes. The quirks that took years to develop.

At some point, switching AI providers doesn't just mean changing software. It means starting over. Rebuilding context from scratch. That's a new kind of lock-in that most companies aren't pricing into their decisions today.

The Numbers That Tell You How Fast This Is Moving

This isn't theoretical. Look at what's already happened:

• Claude Code went from zero to $2.5 billion in annualized revenue in under a year - faster than any enterprise software product in history

• Business subscriptions quadrupled in the first two months of 2026

• 8 of the Fortune 10 are now Claude customers

• Companies spending over $1M annually grew from a dozen two years ago to over 500 today

• When Anthropic's February releases hit, enterprise software stocks sold off sharply and roughly $2 trillion in global SaaS valuations evaporated - and Microsoft integrated Anthropic technology into Copilot within weeks

That last point is key. When urgency spikes this fast, the evaluation process collapses. Procurement timelines compress. The trust analysis gets rushed. And the question stops being "is this safe enough to adopt?" and becomes "can we afford not to move if our competitors already have?"

The permission question - the one with the longest consequences - is getting answered in the shortest windows.

So What Do You Actually Do With This?

Here's the opportunity hiding inside the warning: the companies that think clearly about this now will have a structural advantage over the ones that don't.

That means asking a few questions most companies aren't asking yet:

• Where is your permission line? Is AI advising your business or operating it? Do the people making adoption decisions actually know the difference - or are they just approving "the next upgrade"?

• Who owns your governance layer? If it's the same company that sold you the capability, that's not necessarily wrong - but you should understand the dynamic consciously, not discover it in three years.

• What does switching cost in 2028? Not in licensing fees. In context. In integration depth. In everything the system has learned about how you specifically work.

• Are you making the permission decision under urgency? Competitive pressure is real and legitimate. But "our competitors are moving fast" is a reason to move thoughtfully, not a reason to skip the thinking.

The companies winning this decade won't just be the ones that adopted AI fastest. They'll be the ones that understood what they were agreeing to - and used that clarity as an edge while everyone else was just trying to keep up.

The One Thing Worth Remembering

Legacy software won by storing your records. The next generation wins by becoming the company you trust enough to let inside the moments where your business actually decides, approves, and acts.

That's a different kind of power. And right now, one company - Anthropic - is closer to that position than almost anyone appreciates.

The surface-level story is model versus model. The real story is trust. Who earns enough of it to move from answering your questions to running your operations.

Permission is the new moat. The question is whether you hand it over consciously - or wake up one day and realize you already did.

If this made you think differently about your own AI setup, forward it to someone who's in the middle of these decisions. They'll thank you for it.

And if you want to think through where your own permission line should be - hit reply. I read everything.

The core idea in one sentence

A harness is everything around the AI model that makes it actually useful.

The model is just the brain.
The harness is the body, tools, memory, workflow, and environment that lets that brain do real work.

Think of it like this.

AI model - brain

harness - body + tools + memory

agent- brain + harness working together

Why this concept exists

People used to think the model itself was the most important thing.

Example mindset from a few years ago:

But now people realized something important:

A mediocre model with a great harness can outperform a powerful model with a bad harness.

Why?

Because raw LLMs have huge limitations:

1. No long term memory

2. No real tools

3. No ability to act

4. No persistent workflows

5. No structured planning

A harness fixes all of these.

What a harness actually contains

A harness is basically the software layer around the model.

Typical components:

1. Prompt / system instructions

This tells the model:

• how to behave
• what role it plays
• what tools exist

Example:

You are a coding agent.
You can run shell commands.
You must write tests before implementing code.

2. Tools

A harness lets the model use external tools.

Without tools the model can only talk.

With tools it can act.

3. Memory

LLMs forget everything outside the context window.

Harnesses add:

• vector databases
• session logs
• summaries
• state files

This lets agents remember what happened earlier.

Example:

Claude Code remembering your project.

4. Planning loops

Agents usually run in loops like:

think
act
observe
repeat

Harnesses implement these loops.

Example:

Step 1: understand task
Step 2: create plan
Step 3: execute step
Step 4: verify result
Step 5: continue

Without this the model just answers once and stops.

5. Guardrails

Harnesses also add safety and validation:

• input filtering
• output validation
• test running
• error handling

Example:

If code fails tests → retry.

6. Model routing

Some harnesses use multiple models.

The harness decides which model to use.

Why the same model performs differently in different harnesses

This is the key insight.

Example:

Same model: Claude Opus 4.6

Tool A: basic chatbot
Tool B: Claude Code

Claude Code feels 10x smarter.

Why?

Not because the model changed.

Because the harness changed.

Claude Code harness includes:

• file system access
• terminal execution
• project context
• planning loop
• tool calling
• persistent memory

That environment massively increases capability.

A simple real example

Model alone

Prompt:

markdown

Build me a website

Output:

markdown

Some HTML code

Done.

Model + harness

Harness workflow:

markdown

1 understand request
2 create project folder
3 generate file structure
4 write code
5 run dev server
6 test website
7 fix errors
8 iterate

Now the model behaves like a software engineer.

Same model.
Better harness.

What harness engineering means

Harness engineering is basically:

designing the system around the AI.

Instead of training models, you build:

• tool systems
• memory systems
• agent loops
• evaluation pipelines
• context management

This is why people say:

Because model improvements are slowing down while system design is exploding.

Real examples of harnesses you probably know

ChatGPT

Harness includes:

• chat interface
• browsing
• code interpreter
• memory

Claude Code

Harness includes:

• terminal
• git
• file system
• code execution

Cursor

Harness includes:

• repo indexing
• code editing
• test running
• diff tools

Another way to think about it

AI stack:

application
agent harness
model
GPU infrastructure

Most innovation now is happening in the middle layer.

The harness.

The skills involved in harness engineering

This is basically a mix of:

AI + software architecture.

Skills include:

• prompt engineering
• tool orchestration
• context engineering
• agent loops
• memory systems
• evaluation harnesses
• model routing
• workflow design

The big shift happening in AI

Old mindset:

better model = better AI

New mindset:

better harness = better AI system

This is why even small models can sometimes outperform large ones if the harness is good.

Liked what you read, subscribe to my newsletter. by clicking the button and follow me on social media for more such content.

Codex is not an autocomplete. It's an agent. That one distinction changes everything.

Most people open an AI coding tool for the first time and treat it like a smarter Google. They type a vague question, skim the output, and close the tab disappointed. The problem isn't Codex. It's the mental model.

Autocomplete fills in your next line. An agent reads your codebase, makes a plan, runs commands, writes and tests code, and hands you a diff to review - all on its own.

If you've heard the hype around Codex but haven't known where to start, this guide is for you. No prior experience needed. By the end, you'll know what Codex is, how it thinks, and the habits that separate the developers getting real results from everyone else spinning their wheels.

Here's the thing: Codex is already strong enough to handle hard problems even with an imperfect prompt. But if you want consistent results across complex codebases and high-stakes tasks, you need better habits. These 10 will get you there.

What Is Codex? (And What It's Not)

Codex is OpenAI's AI coding agent. It works inside the CLI, IDE extensions, and a dedicated Codex app.

Here's what makes it different from tools like GitHub Copilot or ChatGPT:

• It can act, not just suggest. Codex reads files, writes code, runs tests, and reviews diffs.

• It works across your whole codebase, not just the line you're currently typing.

• It follows instructions you set in advance, so it behaves consistently across sessions.

• It connects to external tools via MCP (Model Context Protocol) - things like GitHub, Jira, Slack, and more.

Think of it less like a calculator and more like a junior developer you can assign tasks to. A junior developer that's available 24/7, doesn't complain, and gets faster the better you communicate.

Give Codex the Context It Needs to Succeed

Garbage in, garbage out. That rule applies here more than anywhere.

Before you start, include four things in every prompt:

• Goal - What are you building or changing?

• Context - Which files, folders, docs, or errors are relevant? Use @ mentions.

• Constraints - What architecture, conventions, or safety rules apply?

• Done when - What does success look like? Tests passing? Bug gone? Behavior changed?

This keeps Codex scoped. It makes fewer assumptions. It produces work that's actually reviewable.

Start with a few small wins - ask it questions about your codebase or make a scoped fix. Use speech dictation in the Codex app to speed up your iteration loops.

Choosing the Right Reasoning Level

Codex gives you control over how hard it thinks. Most beginners leave this on default and miss out.

Here's a simple guide:

Low is faster. Extra High is more thorough. Matching the level to the task means you're not waiting for deep reasoning on a two-line fix - and you're not getting shallow thinking on a complex refactor.

Plan Before You Code on Hard Tasks

Complex tasks need a plan. Skipping this is how you end up with half-finished code and a context window full of regret.

Three ways to do it:

Plan mode is the easiest. Toggle it with /plan or Shift+Tab. Codex gathers context, asks clarifying questions, and builds a real plan before touching a single file.

Ask Codex to interview you when your idea is fuzzy. Tell it to challenge your assumptions first. Turn the rough concept into something concrete before writing code.

Use a PLANS.md template for longer multi-step work. This is the advanced move - configure Codex to follow a standard execution-plan format so complex workflows stay on track.

The rule: if you can't describe the task clearly in two sentences, have Codex plan first.

The One File Every Codex User Needs: AGENTS.md

Here's a problem every new Codex user hits within the first week: you keep re-explaining the same things.

Your stack. Your conventions. How to run the project. What "done" means. Every new session, you're repeating yourself.

AGENTS.md fixes that.

It's a simple markdown file that Codex loads automatically when it starts working in your repo. Think of it as a README for your AI agent - a one-time setup that makes every future session smarter.

What to put in AGENTS.md:

• Repo layout and important directories

• How to run, build, test, and lint the project

• Engineering conventions and PR expectations

• What "done" looks like and how to verify it

• Do-not rules (things Codex should never touch)

Use the /init command in the CLI to scaffold a starter file. Edit it to match how you actually work. Keep it short and accurate - a 10-line AGENTS.md that's true is worth more than a 100-line one that's vague.

You can stack them: a global ~/.codex/AGENTS.md for personal defaults, a repo-level file for shared standards, and subdirectory files for local rules. More specific files win.

Configure Codex to Match Your Workflow

Random behavior across sessions kills trust. Configuration fixes it.

The pattern that works:

• ~/.codex/config.toml - Personal defaults (model choice, reasoning effort, MCP setup)

• .codex/config.toml - Repo-specific behavior

• CLI overrides - One-off situations only

config.toml is where you set durable preferences. You can edit it directly or ask Codex to update it for you.

Two knobs matter most:

Approval mode controls when Codex asks permission before running a command. Sandbox mode controls what files and directories Codex can access.

If you're new to coding agents: start conservative. Keep permissions tight. Loosen them only for trusted repos once you understand the workflow.

Most quality issues aren't Codex problems. They're setup problems - wrong directory, missing write access, wrong model defaults. Fix configuration first.

Have Codex Test, Validate, and Review Its Own Work

Don't stop at "make the change." That's half the job.

Ask Codex to:

• Write or update tests for the change

• Run the relevant test suites

• Check lint, formatting, and type errors

• Confirm the behavior matches what you asked for

• Review the diff for bugs, regressions, or risky patterns

Codex will do this loop - but only if it knows what "good" looks like. Put that definition in your prompt or AGENTS.md.

Use /review for structured code review options:

• Review against a base branch (PR-style)

• Review uncommitted changes

• Review a specific commit

• Apply custom review instructions

If your team has a code_review.md referenced in AGENTS.md, Codex follows that guidance automatically. Consistent review behavior across every contributor. No manual enforcement needed.

Connect External Tools with MCP

The context Codex needs doesn't always live in the repo. That's where MCP comes in.

Model Context Protocol is an open standard for connecting Codex to external tools and systems. Use it when:

• The data lives outside the codebase

• The data changes frequently

• You want Codex to use a tool instead of relying on pasted instructions

• You need a repeatable integration across multiple users or projects

In the Codex app: Settings > MCP servers. Codex can often help you install the right servers - just ask. In the CLI, use codex mcp add with a name, URL, and any additional config.

Start with one or two tools that remove a manual loop you do constantly. Wire in everything later - not all at once.

Turn Repeated Workflows into Skills

If you keep reusing the same prompt, it should be a skill.

Skills are reusable SKILL.md files that package the instructions, context, and logic Codex should apply consistently. They work across the CLI, IDE extension, and Codex app.

What makes a good skill:

• Scoped to one job

• 2-3 concrete use cases defined upfront

• Clear inputs and outputs

• Description written for trigger phrases a real user would say

Don't try to handle every edge case. Get one workflow working well, then turn it into a skill and improve from there.

Good candidates for skills:

• Log triage

• Release note drafting

• PR review against a checklist

• Migration planning

• Incident summaries

• Standard debugging flows

Use $skill-creator to scaffold your first skill. Use $skill-installer to install it locally.

Personal skills live in $HOME/.agents/skills. Team skills check into .agents/skills in the repo. This makes onboarding new teammates significantly faster.

8. Automate Stable Workflows

Once a workflow is predictable, stop running it manually.

Automations in the Codex app let you schedule tasks in the background - choose the project, prompt, cadence, and execution environment. You can invoke skills inside automations.

Good automation candidates:

• Summarizing recent commits

• Scanning for likely bugs

• Drafting release notes

• Checking CI failures

• Producing standup summaries

• Running repeatable analysis on a schedule

The rule: skills define the method, automations define the schedule. If a workflow still needs steering, make it a skill first. Once it's predictable, automation multiplies the output.

Don't automate something you haven't done reliably by hand. That's how you get confidently wrong outputs running on a schedule.

9. Manage Sessions Like a Pro

Codex sessions aren't just chat history. They're working threads that accumulate context, decisions, and actions over time.

Key slash commands for the CLI:

• /resume - Pick up a saved conversation

• /fork - New thread, original transcript preserved

• /compact - Summarize earlier context when the thread gets long

• /agent - Switch between active agent threads in multi-agent workflows

• /status - Check current session state

One thread per coherent unit of work. If it's still the same problem, stay in the same thread - the reasoning trail is valuable. Fork only when the work truly branches.

For parallel work on the same files, use git worktrees. Running multiple threads on the same files without worktrees is how things break.

The Mistakes That Kill Your Results

Most Codex frustration comes from the same five mistakes:

1. Loading durable rules into prompts instead of AGENTS.md - You're repeating yourself every session.

2. Not giving Codex build and test commands - It can't validate work it can't run.

3. Skipping planning on complex tasks - Execution without a plan produces messy code.

4. Giving full permissions before you understand the workflow - Start tight, loosen later.

5. Automating before the workflow is reliable - Manual first. Automate second.

The sixth one is subtle: watching Codex run step by step like it needs supervision. Once you've set up a solid prompt and AGENTS.md, let it run. Come back to the diff. That's how you use it in parallel with your own work.

Your Getting Started Checklist

• [ ] Include goal, context, constraints, and done-when in your prompts

• [ ] Use Plan mode for complex or ambiguous tasks

• [ ] Create a starter AGENTS.md with /init

• [ ] Tell Codex how to build, test, validate, and review

• [ ] Set configuration defaults in config.toml

• [ ] Add MCP for your highest-value external tools

• [ ] Turn your first repeated workflow into a skill

• [ ] Automate once the workflow is stable

The more you encode your workflow into Codex - your standards, your context, your definition of done - the more you'll understand what the agent can actually do.

Most people never get there. You now know why.

Liked what you read, subscribe to my newsletter. by clicking the button and follow me on social media for more such content.

LinkedIn : https://www.linkedin.com/in/adnaankhan98/

Instagram: https://www.instagram.com/theadnaankhan/ 

Twitter: https://twitter.com/theadnaankhan

01. the paradigm shift

historically, the barrier was the code. to build software, you had to become a programmer first. you spent years fighting errors and memorizing rules instead of actually bringing your ideas to life.

that era ended.

andrej karpathy (founding member of openai, ex-tesla ai) defined the shift: “there’s a new kind of coding i call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

vibe coding is not about laziness. it is about abstraction. just as we stopped writing binary and started writing python, we are now stopping writing python and starting to write intent.

you are no longer the bricklayer. you are the architect.

02. the core philosophy

before touching a tool, you must understand the mental model. if you treat ai like a fancy autocomplete, you will fail. if you treat it like a junior developer, you will win.

the vibe loop:

1. contextualize: feed the ai the big picture.

2. architect: ask for a plan, not code.

3. generate: let the ai handle the implementation.

4. audit: verify the output (visually and functionally).

5. iterate: refine based on vibes (ux/ui) and logic.

there are two paths to this. choose yours.

path a: the builder

target: developers, technical founders, students. goal: high-control, production-grade software. primary weapon: cursor/antigravity.

the stack

• cursor/antigravity: this is your ide. it is a fork of vs code with an ai brain integrated into the compiler and file system. it doesn't just "see" the file you are working on; it sees your entire repository.

• claude (anthropic): the brain. use claude.ai for high-level logic and architecture.

• chatgpt - needs no introduction

• claude code: the agent that can edit your files directly.

• codex- openai’s coding agent

phase 1: the environment

don't just install it. set it up for speed.

1. download cursor/antigravity.

2. go to the chat mode (this is the agentic mode that can edit multiple files across your project simultaneously).

3. pro tip: create a file in your root folder called .cursorrules. in this file, write instructions like "always use typescript," "prefer tailwind for styling," or "no class components, functional only." the ai will read this before every single response.

phase 2: the initialization (prompt engineering)

never start by asking for code. start by establishing truth.

1. open a new window. create a blank folder.

2. open composer (cmd+i / cmd+l).

3. write the spec. type this exact prompt structure:

create a detailed readme.md for a project called [name].

project goal:
[2-3 sentences on what the app does]

tech stack:
- frontend: react, vite, tailwind, shadcn/ui
- backend: supabase or firebase (choose one)
- language: typescript

requirements:
- define 5 distinct development milestones.
- milestone 1 must be a "hello world" setup with the basic layout.
- include a file structure overview.

read the readme the ai generates. modify it manually if it's wrong. this file is now your source of truth. the ai will reference it constantly.

phase 3: the execution (milestone by milestone)

do not try to build the whole app in one prompt. complexity kills the vibe.

step 1: scaffolding

• in composer: "read the readme. execute milestone 1. setup the project structure, install dependencies, and create the basic landing page shell."

• cursor/antigravity will create 15+ files at once.

• open your terminal in the editor: npm run dev.

step 2: the visual loop

• look at localhost:3000.

• is it ugly? take a screenshot. drag the screenshot into cursor/antigravity chat.

• prompt: "match the design in this screenshot exactly. use a dark theme."

• is it broken? copy the error from the terminal. paste it into chat.

• prompt: "fix this error. explain what went wrong."

step 3: logic injection

• when adding complex logic (e.g., auth), ask for a plan first.

• prompt: "i want to add user authentication. check the readme. explain which files you need to create and how the data flow will work. do not code yet."

• verify the logic. then say: "execute plan."

phase 4: debugging via context

when things break (and they will), it’s usually because the ai forgot the context.

• use the @ symbol. in cursor/antigravity, typing @Codebase forces the ai to re-read your whole project.

• prompt: "@Codebase why is my login button not redirecting to the dashboard? check the routing configuration."

path b: the visionary

target: non-technical founders, designers, pm's. goal: rapid prototyping, mvps, internal tools. primary weapon: replit, lovable

the stack

• replit: cloud-based ide. zero setup.

• replit agent: an autonomous ai worker that has permission to run terminal commands, install packages, and edit code.

• lovable - one of the best in browser vibe coding platforms

phase 1: the specification

since you aren't writing code, your english must be impeccable. ambiguity is your enemy.

the golden prompt structure: [just an example]

role: senior full stack developer
goal: build a [app type] called [name]

core features:
1. user authentication (email/pass)
2. [feature a] - include specific details
3. [feature b] - include specific details

data model:
- users (id, email, name)
- [entity a] (id, title, status, date)

design system:
- clean, minimal, lots of whitespace
- primary color: #000000
- font: inter

phase 2: the agent workflow

1. create a new repl. select agent.

2. paste your golden prompt.

3. watch. the agent will start "thinking." it will write a plan. it will install packages. it will set up a database.

4. intervene. sometimes the agent pauses to ask for clarification. answer simply.

phase 3: visual debugging

click "run". your app opens in a webview.

• act like a malicious user. try to break forms. try to submit empty data.

• when you find a bug, talk to the agent like a project manager.

phase 4: iteration

once the base is done, treat it like a sculpture.

• "change the background to a soft gray."

• "make the cards look like glassmorphism."

• "add a confetti animation when a task is completed."

03. advanced techniques: mastering the vibe

1. the ".cursorrules" meta-strategy

in cursor/antigravity, this file is your superpower. put this in your root directory to make the ai smarter:

# .cursorrules
- be concise. do not explain the code unless asked.
- always add comments to complex logic.
- use modern react (hooks, functional components).
- if you change a file, ensure you don't break imports in other files.
- always error handle async functions with try/catch.

2. screenshot-driven development (sdd)

never describe ui with words.

• find a site you like on dribbble or pinterest.

• screenshot it.

• paste into cursor/antigravity.

• prompt: "make my dashboard component look exactly like this image. use tailwind css."

3. the "revert" safety net

in vibe coding, you move fast. sometimes you move too fast and the ai hallucinates garbage code that breaks everything.

• do not debug garbage.

• use git checkout . or the "timeline" feature in cursor/antigravity to roll back to the last time it worked.

• rephrase your prompt and try again. it is faster to rebuild than to repair.

4. documentation is code

if you want to add a huge feature, don't tell the chat.

• write a new markdown file called feature-spec.md.

• outline the feature in detail in that file.

• tell cursor/antigravity: "read feature-spec.md and implement it."

• this keeps the ai focused and provides a permanent record of what you wanted.

04. conclusion

vibe coding is a skill of communication, not memorization.

the code is just an implementation detail. your ability to clearly visualize a product, break it down into logical steps, and guide the ai through the execution is the only thing that matters.

open cursor/antigravity. write the readme. give in to the vibe

While you've been grinding away at keyword research, building backlinks, and obsessing over your Google rankings, something fundamental changed.

Your audience stopped Googling.

They're asking ChatGPT. They're asking Perplexity. They're asking Gemini.

And your carefully optimized content? It's invisible.

The Shift Nobody Saw Coming

Here's what's actually happening right now in 2025.

Traditional SEO assumed everyone saw the same search results. You fought for that #1 position because it meant visibility for everyone who searched that term.

AI search flipped that entire game.

Now, two people can ask the exact same question and get completely different answers. Because AI search remembers who you are. It knows your context. It personalizes every single response.

The game isn't about ranking #1 anymore.

It's about being mentioned everywhere.

Why This Matters More Than You Think

You know that feeling when you've been working hard on something, doing everything "right," and then you find out the rules changed six months ago?

That's where most content creators are right now.

They're still optimizing for Google's algorithm while their competitors are showing up in AI-powered conversations with highly qualified buyers.

And here's the kicker: people who find you through AI search are 6x more likely to actually buy from you.

Why?

Because they didn't just click a link. They had a conversation with an AI about their specific problem, and your solution came up naturally in that conversation. By the time they reach you, they're not browsing. They're ready.

The Resources That'll Actually Help

So many of you hit me up asking how to get started with AI search. You wanted the real resources, not surface-level blog posts.

Here's what you actually need to read.

1. Lily Ray's Substack: "Why Search Engines Panicked in 2025"

This article breaks down exactly what happened when search engines realized everyone was bypassing them for ChatGPT.

The key insight? AI doesn't look for keywords.

It breaks your question into a dozen smaller questions to build a comprehensive answer. Think about that for a second. When someone asks "What's the best project management tool for remote teams?" AI search doesn't just look for those exact words.

It asks itself:

• What makes a project management tool effective?

• What are the unique challenges of remote teams?

• What features matter most for distributed collaboration?

• What do current users say about different tools?

• What's the price range for these solutions?

Then it synthesizes answers from multiple sources to build one coherent response.

Your old SEO strategy wasn't built for this. You were optimizing for one keyword. AI is looking for comprehensive, interconnected value.

A Reflection on SEO, GEO & AI Search in 2025

Search transformed dramatically in 2025. Learn about the biggest changes in SEO & AI search, including my observations, hot takes, and predictions for where search is headed in 2026.

lilyraynyc.substack.com/p/a-reflection-on-seo-and-ai-search

2. The Perplexity Deep Dive: How AI Shreds Your Content

This interview gets technical, but in the best way.

It shows you exactly how AI search engines like Perplexity process your content. They don't read your webpage top to bottom like Google does.

They shred it.

Imagine taking your beautifully crafted 2000-word blog post and cutting it into tiny snippets of 2-4 words each. That's what AI does. It breaks your content into atomic units of meaning.

Then it indexes those snippets individually.

This means:

• Your intro doesn't matter as much

• Your conclusion doesn't matter as much

• What matters is whether each paragraph, each sentence, each phrase delivers standalone value

One killer insight buried in paragraph 12? AI will find it and surface it, even if nobody reads the full article.

One fluffy paragraph with no real value? It's ignored, even if it's at the top.

The implications are massive. You can't hide weak content behind strong headlines anymore. Every single line needs to earn its place.

Perplexity AI Interview Explains How AI Search Works

Interview with Perplexity AI explains how AI Search works and provides insights into answer engine optimization

www.searchenginejournal.com/perplexity-ai-interview-explains-how-ai-search-works/565395

3. Ethan Smith's Podcast: "The Startup Cheat Code"

This one changed how I think about distribution entirely.

Smith breaks down why AI search is the ultimate cheat code for startups and creators. The insight about 6x conversion rates? That comes from here.

But the deeper point is about how AI search fundamentally changes discovery.

In Google, you won if your link was #1 for a specific search term. That's a binary outcome. You're either visible or you're not.

In AI search, you win by being mentioned the most across the most diverse sources.

Your startup gets mentioned on Reddit? That counts.

Someone makes a YouTube video about your tool? That counts.

You write a detailed answer on a forum? That counts.

You publish consistent blog content? That counts.

AI aggregates all of these mentions and references to build a composite understanding of who you are and what problems you solve.

This means the traditional playbook of "rank #1 for our target keyword" is dead.

The new playbook is "be helpful in as many places as possible."

Which, honestly, is how it should have been all along.

4. HubSpot Field Notes: The Tactical Playbook

Okay, this is where theory meets practice.

HubSpot's field notes give you the actual tactical playbook for formatting your content so AI can find it and use it effectively.

The big idea: atomic units.

Remember how Perplexity shreds your content into snippets? HubSpot shows you how to structure your content so those snippets are actually useful.

Instead of this: Long paragraphs that combine multiple ideas, mixing context with examples and jumping between different points without clear separation, making it impossible for AI to extract clean insights because everything's blended together into one massive wall of text that requires reading the entire thing to understand any single point.

Do this:

One paragraph. One idea.

Each paragraph should be able to stand alone. If someone only read that single paragraph, they should get complete value from it.

This isn't just good for AI. It's good for humans too.

Short paragraphs. Clear ideas. Scannable structure.

The guide also covers technical SEO for AI, schema markup that actually matters now, and how to structure your site architecture so AI can navigate and understand your full knowledge base.

It's the most practical piece on this list.

What This Means for You

Here's the uncomfortable truth.

The shift already happened.

You're not preparing for the future of search. You're catching up to the present.

Every day you spend optimizing for Google's 2020 algorithm is a day your competitors are building presence in AI search.

And here's what makes this urgent: AI search has a compounding effect.

The more you're mentioned, the more you get mentioned. The more AI sees your content cited, referenced, and linked to, the more confident it becomes in surfacing you as an answer.

It's a flywheel. And right now, you're either spinning it or you're not.

Your Next Move

Start with these four resources. Actually read them, don't just skim.

Then audit your content through this new lens:

• Can each paragraph stand alone?

• Are you being mentioned across multiple platforms?

• Is your content formatted for extraction, not just reading?

• Are you answering specific questions, or just writing about topics?

The creators who figure this out now will dominate their niches for the next five years.

The ones who don't will keep wondering why their traffic is bleeding out.

You're either invisible or you're everywhere.

Choose.