One Sketch Away

Your Ide Just Got Smarter Again But This Time Its Not Just About Code

Your IDE Just Got Smarter. Again. But This Time It’s Not Just About Code.

codex

Last year, I wrote a blog titled “Your IDE Just Got Smarter, Have You?” — mostly focused on AI helping us write code faster inside the editor.

Since then, agentic tools have evolved fast. They don’t just autocomplete anymore. They can take actions, modify files, plan multi-step work, and even run tasks in the background.

Over the past week, I’ve been using Codex daily. And what stood out wasn’t just capability — it was the feeling of partnership. Not “generate this for me,” but “work with me.”

If you want a solid overview straight from the OpenAI Codex team, their walkthrough is a good starting point: 🔗 https://www.youtube.com/watch?v=px7XlbYgk7I

A Note on My 1-Week Experiment

I’ve been testing this for about a week now, using a mix of gpt-5, gpt-5.2, and grok-code-fast models.

One pattern showed up almost immediately:

Higher-reasoning models think deeper, but take longer

Faster models respond quickly, but with lighter reasoning

Neither is universally “better.” It depends entirely on what you’re doing.

And once you start using a CLI workflow, switching models becomes trivial — which makes it easy to pick the right tool for the job on the fly.

A Quick Evolution: From Smarter IDE → CLINE → Codex

Tools like CLINE helped popularize agentic patterns — the ability to take actions, modify files, and move beyond simple autocomplete. It showed many of us what agentic workflows could look like.

Codex feels like the next step in that progression. Not because it introduces completely new features — many of these patterns already existed — but because the experience feels different.

With CLINE, it often felt like invoking a very capable tool. With Codex, it feels more natural to say:

It’s a subtle shift. But once you feel it, it changes how naturally you reach for it.

My Top 10 Highlights After 1 Week with Codex

This isn’t a product review. It’s just what stood out to me after spending a week with it — the things I keep thinking about.

1. It’s Not Autocomplete — It’s a Teammate

I want to get this one out of the way first because it reframes everything else.

Codex doesn’t feel like a smarter autocomplete. It feels like a software engineering teammate that happens to live inside your terminal. It can understand your repo, explain architecture decisions, plan work, implement changes, then review and validate what it built.

That’s not an incremental improvement on autocomplete. It’s a different category of tool entirely.

The mental model shift matters. When you think of it as autocomplete, you use it passively. When you think of it as a teammate, you start delegating, reviewing, and iterating — the way you would with a junior engineer who’s fast and eager but needs direction.

2. Codex Is Not Just About Code

Codex is genuinely useful for non-coding tasks such as:

And the key difference is this:

Codex can execute things behind the scenes.

If the task needs Python, Bash, or file generation steps, Codex can generate the code, run it, and deliver the final output — without you needing to do the scripting yourself.

This is why I say Codex is not just “for code.”

It’s a workbench.

3. Skills + MCP: Real Capability, Not Just Chat

This is one of the most important concepts if you want serious mileage out of Codex.

Skills are built-in capabilities that let Codex do actual work — not just generate text. Think: file operations, browser automation, document generation, system commands, structured outputs. When the right skill is available, Codex moves from “here’s a suggestion” to “here, I did it.”

Then there’s MCP (Model Context Protocol) — which enables clean integration with external systems. For example, Figma integration becomes possible through MCP-style connectivity. You can also paste images directly into the workflow and have Codex reason about them.

We’ve seen skills and MCP-style patterns before in other agentic tools. The difference now is how cleanly and reliably everything feels wired up. It’s less “let me hack this together” and more “this just works.”

One example from my own testing: Playwright was available as a skill out of the box. I described a UI workflow in plain English — open browser, navigate tabs, input values, validate output — and Codex automated a real browser session without me writing a single test script.

The point isn’t Playwright itself. The point is that skills let you automate real-world tasks without first learning the tooling.

4. Plan Mode: The Most Underused Superpower

Most people interact with AI like this:

“Build this feature.”

And then hope for the best.

Plan Mode changes the dynamic entirely. Instead of jumping straight into implementation, you tell Codex:

“First, plan it. Then build it.”

In Plan Mode, Codex breaks the task into steps, identifies dependencies, calls out assumptions, and defines milestones — before writing a single line of code.

You review the plan, adjust it, then let it execute.

A simple habit that works extremely well: keep a plan.md file in the repo with goals, a checklist, milestones, and progress updates. Ask Codex to follow the plan and update it as work gets done.

It sounds almost too simple, but it dramatically reduces:

What you get instead is:

This is where we move from a “vibe coding” mindset to actual engineering discipline, even when the AI is doing the heavy lifting.

5. Markdown as a Shared Contract (AGENTS.md, SKILLS.md, plan.md, etc.)

One of the most practical ideas coming from the Codex team is using a handful of Markdown files as a shared contract between you and the AI.

Simple, lightweight, no special tooling required.

AGENTS.md

Think of this as a README for agents (and humans). It tells Codex how to behave in your repo.

Best practices:

SKILLS.md

SKILLS.md documents how a specific skill works and how the agent should apply it:

plan.md

Keeps execution disciplined and prevents drift.

The best part?

You don’t have to maintain these files manually. You can tell Codex in natural language to update them, and it will.

Your docs become useful for both humans and AI — which, if we’re honest, is more than most of our docs achieve today.

6. Parallel Thinking: Don’t Wait While the Model Thinks

Reasoning models take time. That’s the trade-off for deeper thinking.

But here’s what changes the game:

You don’t have to sit there and wait.

You can kick off a deep task — something that requires serious reasoning — and immediately start another task in a separate session. The AI thinks in the background while you keep moving.

You come back later, review the output, and iterate.

It sounds small on paper, but in practice it completely changes the work rhythm. Instead of a sequential back-and-forth, you’re working more like a tech lead with multiple contributors running in parallel.

You’re reviewing, steering, and unblocking — not waiting.

7. Git Worktrees: Clean Parallelism for Real Repos

Git worktrees are not new — they’ve been in Git for years. But Codex makes them feel far more relevant now.

Because we can run multiple agentic sessions in parallel, we need a clean way to isolate work.

A worktree lets you have multiple working directories, each tied to a different branch, without conflicts or index locking.

So you can have:

All running at the same time.

This is the clean, safe way to do parallel AI work on a real repo, without stepping on each other’s toes.

8. The CLI: Why Use a Terminal in 2025?

I know what some of you are thinking: why are modern AI tools going back to the command line? We have beautiful IDEs. We have GUIs. The CLI looks… old.

But there’s a reason tools like Claude Code and Codex chose CLI as a first-class interface:

Some of us still prefer tools like sqlplus for serious SQL work — not because GUIs are bad, but because CLI tools are precise, scriptable, and predictable. The same logic applies here.

The CLI isn’t a step backward. It’s a deliberate choice.

And one more thing: getting used to the Codex CLI is much easier than most people expect. You’re not memorizing a new command language — you’re still typing in natural language.

Even if you don’t remember commands, you can interact naturally and let Codex guide you. And you get the benefit of lightning performance, clear visibility into actions, and none of the extra GUI/browser sugar-coating.

9. Slash Commands: The Hidden Superpower

The CLI supports a set of slash commands that are deceptively powerful:

But the real unlock is that you can define custom slash commands.

That’s huge.

It means you can build repeatable workflows tailored to your team:

Slash commands turn Codex from an interactive chat into a programmable teammate.

10. Prompting Practices That Actually Make a Difference

After a week of daily use, one thing is clear:

Better prompts aren’t longer — they’re clearer.

A few habits consistently improve results:

Point Codex to the right code. Mention specific files, functions, classes — even commit hashes when needed. Clear scope = better output.

Ask for verification. Tell it to run tests, lint, and check edge cases. If you don’t ask, it often won’t.

Start small before going big. Break work into steps. Implement step 1, validate, then move to step 2.

Paste the full stack trace. Codex is excellent at reading stack traces — give it the full output, not a summary.

Use open-ended prompts sometimes. Ask: “What could be improved?” “Where is test coverage weak?” “Any performance issues?”

Bonus: Codex Prompts You to Prompt It

In CLI mode, Codex often suggests the next question proactively — basically prompting you to prompt it.

Sometimes it’s a bit annoying and you just want it to be quiet 😄, but more often than not it nudges you toward something useful.

It makes the tool feel less like a search box and more like a thinking partner.

After One Week with Codex

After one week of using Codex, I genuinely feel there is an awesome partnership forming — both for coding and non-coding tasks.

I’ve shipped real work using Codex. I’m also writing this blog using Codex.

There’s still a lot more for me to explore:

I’ve already developed my first skill — generating real PowerPoint slides using a Redwood template. It works, but I need to iteratively improve it to make it more useful and production-ready.

I also need more hands-on practice — more keyboard shortcuts, more muscle memory, more natural delegation.

I know tools will come and go.

But this shift — this way of working — feels like something that will stay with me for a long time.

And that, more than anything else, is what makes this exciting.