Practical tutorial
How to use Codex inside IntelliJ IDEA step by step
A practical guide to using IntelliJ or WebStorm as the working surface while Codex inspects the real repository, proposes changes, runs checks and helps you review the result without losing engineering control.
CodexIntelliJ IDEAWebStormCLIAppPromptingReview
What is worth understanding before you start
This tutorial is designed to work with Codex from inside IntelliJ or WebStorm itself, using the real project as the source of context and not a disconnected conversation.
Codex performs better when it starts from the real project
In IntelliJ, the value is not in asking for code in the abstract, but in letting it inspect routes, components, data, styles and repository conventions before touching anything.
You do not need to give up control to save time
The good workflow is to delegate searches, edits and specific checks, while keeping the final acceptance of the change and the functional validation for yourself.
The best results come from small, precise and verifiable prompts
If you define the route, the component, the tone of the tutorial, the assets and the way to validate it, Codex can iterate with much less friction.
Codex does not replace your technical judgement: it speeds up the mechanical part if you give it a clear working frame
The difference between a mediocre session and a really productive one usually lies in how you frame the first instruction. If you open IntelliJ, locate the routes and equivalent components, and then formulate the change as a verifiable task, the agent can operate with much more precision. If, on the contrary, the request is ambiguous, the tool will tend to fill gaps with assumptions.
Preparation
How to prepare IntelliJ for a coding session with Codex
You do not need to set up anything exotic. What matters is reducing visual friction and keeping accessible the pieces the agent will need to inspect. The faster it can orient itself in the repository, the less time it will lose inventing context.
Open the correct project in IntelliJ IDEA or WebStorm and keep the file tree visible.
Keep the main router, similar components and the assets folder at hand so Codex has clear references.
Phrase the task as a concrete repository change, not as an abstract question.
State whether you want a minimal fix, a complete page or a refactor with verification included.
Workspace
Recommended layout inside the IDE
A practical setup is to keep the project tree on the left, the main file in the center editor and a terminal or agent panel where Codex can inspect and validate. The point is not to open everything, but to open enough for navigation and review to stay fast.
Left panel
Use the file tree to jump between `src/app`, `src/assets` and supporting data. If the change touches routes, components and JSON catalogs, having those folders two clicks away saves quite a bit of time.
Center editor
Open a reference close to the change you want to make first. Asking for a new component based on an existing one usually produces a better output than starting without any visual or technical reference.
Terminal or agent panel
Reserve it so Codex can inspect, edit and validate. That is where it pays off to delegate searches, route reading, targeted modifications and compilation or consistency checks.
Current workflow
What "using Codex inside IntelliJ" really means
The important idea is not the name of the panel, but the shared working context. IntelliJ or WebStorm keeps the repository visible; Codex can work from the terminal, app or agent surface; and you keep the final review in the IDE where the code actually lives.
IntelliJ or WebStorm
Keep the project open, use the file tree and editor as your reference point, and let Codex work against the same repository instead of a copied snippet.
Integrated terminal or Codex CLI
A good JetBrains workflow is to run Codex from the project root, so it can inspect files, apply patches and execute the same build commands you use.
Codex app and cloud tasks
For longer work, parallel investigation or follow-up tasks, the app and cloud flow are useful because they keep context beyond a single quick edit.
Diff and local validation
The IDE remains the place where you inspect changed files, compare the patch, run the app and decide whether the result is acceptable.
Method
Step by step workflow
This is the pattern that gives the best balance between speed and control. It works both for small changes and for longer editorial tasks, such as adding a complete tutorial page with assets and its own route.
Ask for inspection before asking for code
Start with an instruction that forces a review of routes, existing components, reusable styles and supporting data. That reduces assumptions and makes the solution respect the real structure of the project.
Pin down the exact deliverable
If you want a tutorial page with its own route, say so with the slug, the expected folder, the component type, the tone of the article and whether it should appear in the blog listing.
Limit the technical scope
State whether it should be standalone, whether it has to use existing visual helpers, whether SEO goes in the component itself and whether you prefer locally created SVG assets.
Make it run validation
After the patch, ask for a real check: build, test, typecheck or at least a final read of imports, routes and touched JSON files. Without that, the task is left half done.
Review the diff like a small PR
Check that the change does not only compile: the route must load, the listing must link well, the assets must exist and the tutorial text must answer exactly what you asked for.
Iterate on the result, not on the original idea
Once the first patch exists, the best way to improve the output is to ask for concrete changes on that diff: more detail, another visual structure, another slug or a copy adjustment.
Playbook
How to change the prompt depending on the task
The same style of instruction does not work equally well for a bug, a new article, a refactor and a review. Codex becomes more useful when the request matches the kind of work you are delegating.
When the task is a bug
Ask Codex to reproduce the mental path first: where the data comes from, where it is transformed and where it is rendered. Then request the smallest change that fixes the user-visible behavior.
When the task is a new article
Give the slug, language expectations, catalog entry, SEO target and validation command. A new article is not finished until route, listing, metadata and build all agree.
When the task is refactoring
Limit the write scope. Refactors are where agents can become too enthusiastic, so make it preserve public behavior and avoid unrelated cleanup.
When the task is review
Tell it to lead with findings, line references and severity. This changes the mode from "make more code" to "protect the codebase".
Prompts
Prompt patterns that usually work well
A good prompt for Codex inside IntelliJ looks more like a short specification than a chat. It should say what to inspect, what to create, what not to touch and how to verify that the task is closed.
Prompt to start well
I want a new tutorial page about how to use Codex inside IntelliJ IDEA.
Review the project structure first and detect where routes, posts and assets live.
Then create a long standalone component with SEO, two local images and a new route /how-to-use-codex-in-intellij-idea.
If the blog uses a catalog or snapshot to list posts, add it there as well.
Validate at the end that imports and JSON were not broken.This prompt works because it marks prior inspection, deliverables, constraints and validation.
Prompt for a second pass
On top of the component already created, I want a second pass.
Make the tutorial more editorial and less generic: add a common mistakes section,
another one with recommended prompts and a final checklist before accepting changes.
Do not change the route or the slug.This forces iteration on a real artifact instead of starting again from scratch.
Prompt for review mode
Review the changes in this tutorial as if it were a code review.
Prioritize bugs, regression risks, route errors, broken imports, invalid JSON,
missing images and text that contradicts the current project structure.It is useful when you no longer want more writing, but a critical reading of the patch.
Prompt for a bug fix
There is a bug in the project listing: searching for "odoo" does not show the Odoo posts.
First inspect the listing component, the catalog source, the snapshot and the route definitions.
Explain the cause briefly, then apply the smallest fix that makes the search work by title, topic and URL.
Regenerate derived assets only if the project requires it and run the build afterwards.This is effective because it asks for diagnosis before editing and defines the exact observable behavior.
Prompt for SEO/content improvement
Improve this existing article without changing its route.
Keep the bilingual structure, preserve the current visual style, expand weak sections,
improve the meta description and validate that the page still builds.
Do not rewrite unrelated files.Useful for blog maintenance because it protects the URL while still allowing a meaningful content pass.
Real practice
How to ask for a complete task without loose ends
Suppose you want exactly what has been done on this page: a new component, a public route, a long tutorial, its own assets and appearance in the main blog listing. The good request is not "create a page about Codex", but an instruction like this.
Brief but effective specification
Create a new Angular tutorial component about how to use Codex inside IntelliJ IDEA.
It must have its own route, long-form content in Spanish, two local WebP images,
SEO configured in the component and registration in the blog catalog if it exists.
Use the modern visual style of the project and validate imports, routes and JSON at the end.With this you give it enough freedom to execute, but not so much that it drifts toward solutions that do not fit the repository. If later you want to refine tone, structure or visuals, you do it in a second pass.
Checklist before accepting the changes
- The route is registered in the main router and points to the correct file.
- The new component is standalone and its imports match the helpers used in the template.
- The images really live in `src/assets` and their paths match the HTML `src` values.
- The tutorial has a coherent title, description and canonical URL for SEO.
- The catalog JSON files remain valid and the new article appears in the listing.
- Derived files such as snapshots, sitemaps or SEO metadata are regenerated only when needed.
- The validation command is real: build, tests, typecheck or an equivalent project command.
- The layout behaves correctly on desktop and mobile.
Patterns worth avoiding
- Asking for "make me a tutorial" without saying where it should live, how it is published or how it is validated.
- Requesting large changes across several subsystems without organizing the work into phases.
- Assuming that a long result is automatically good: if the prompt is vague, filler grows and precision drops.
- Accepting the patch without reviewing the diff, imports, routes and touched data files.
- Using Codex like an isolated chatbot when the real advantage lies in operating on the open repository.
Judgement
When to use Codex and when to slow down
Codex is especially useful for structured work: locating files, following conventions, propagating an existing pattern, creating new pages, adjusting imports, touching routes and validating consistency. If the task has a lot of product ambiguity, open architecture or functional decisions that still have not been made, it is better to close the human judgement first and ask for execution afterwards.
Very good fit
Bounded changes, small or medium features, tutorials, UI sections, local refactors, reference searches and technical reviews over specific diffs.
Medium fit
Large restructurings where you have not yet decided the final model. Here it helps more as support for analysis and exploration than as the direct executor of a closed solution.
Poor initial fit
Requests where neither the problem is well defined nor there is acceptance criteria. If your brief is blurry, the result will also tend to be blurry.
Useful next readings
If you are going to keep building technical content in this project, these three pages fit well with the workflow described above.
View Angular routing
Useful if you want to link this workflow to the route pattern used by the project.
View Angular SEOThis complements the tutorial if you are going to publish new pages and want to tag them well.
View responsive videosA good example if you later want to enrich your tutorials with embedded media.
Review SSR and SEOUseful when the page includes code blocks and still needs clean server-rendered HTML.
Secure an Angular APIA stronger backend example if your Codex task touches API keys, proxies or deployment security.
Install Odoo on AWSA longer infrastructure article that benefits from the same inspect-edit-validate workflow.
Consume APIs from AngularUseful when you ask Codex to connect a frontend component with a REST endpoint.
PageRank and internal linksBackground reading for why real links and related posts matter for discovery.