My Poor Man's AI Coding Setup (Jan 2026)

Source: Dev.to

My Setup

I use both Codex and Claude Code and switch between them depending on the task.
The VS Code / Cursor IDE extensions let me add context, see the code, and make adjustments quickly.

I rarely use Cursor Agent Mode or Composer these days. (Even with Opus 4.5, the harness matters – I get better results with Claude Code CLI or the extensions.)

Cursor still has handy features, like browser editing, which is especially useful for frontend work.

I often run both models at the same time on different parts of the code or on complementary tasks, and I ask Codex to review Claude’s output and make follow‑up changes.

IDE extensions! Blasphemy! Get out of here! 😂 Stay with me!

Codex GPT 5.2 (thinking high)

Codex doesn’t need a lot of context, planning, or complex prompts – it usually gets it right the first time with the right pointers, but it is very, very slow.

I use it mostly for complex tasks that require deep thinking:

• Complex bugs
• Strong typing
• High‑data‑accuracy tasks (e.g., converting or scraping data without hallucinations)
• Code review
• Refactors
• Explaining the codebase or individual pieces of code

Favourite follow‑up prompts

• “Is there anything we should refactor?”
• “Simplify this file.”
• “This works, but are there any maintenance, security, or architecture issues?”
• “This works, but is there a better way to achieve the same outcome? Show me options.”

Claude Code / Opus 4.5

Claude Code with Opus 4.5 is very fast and accurate. It sometimes needs a bit more hand‑holding than Codex and will often ask you questions or add a plan. You can also trigger “plan mode” manually. I have mixed results with plan mode – I like it, but for established codebases I prefer smaller, encapsulated changes; Codex usually works better even without a plan.

I use it for most coding tasks:

• New features
• Adding tests / types
• Creating React components
• Quick prototypes

Favourite prompts

• “Design an interface for a library.”
• “Implement a similar method based on this pattern.”
• “Create a component to do X” (it will one‑shot it with great UX).
• “Rename this function/file and update all references and tests.”

Claude Code and Codex CLIs

I also have the CLIs installed. Allegedly they have a more powerful harness, and some features appear first in the CLIs before the IDE extensions catch up.

• IDE extensions provide a single‑threaded workflow: you constantly steer the model, review every line it produces, make inline changes, test, and verify. Only one concurrent session is possible (unless you clone the repo into a separate folder and open another IDE window, which I sometimes do).
• CLIs enable more parallel, hands‑off work (don’t confuse this with “vibe coding” – you still need to read, verify, and ensure the code does what you expect).
• The CLIs require you to think about conflicts, branching, and work‑tree management when running them concurrently on the same codebase. Sometimes they stay clear of each other, but not always. I find this a bit of a faff and avoid it unless I really need to push a lot of things at once.

Not all types of work and repositories are suited for parallel coding with CLIs.

Situations where I find the CLIs useful

• Throw‑away POCs
• Migrations (see Ralph Loop coding below)
• As a starting point before transferring to hands‑on editing in the IDE
• Well‑defined work in projects with strong verification loops (tests)

Ralph Loop Coding

The technique everyone is talking about… I started experimenting with it, and it seems like the end‑game for hands‑off / parallel automated work.

Codex is great for one‑shot, single‑prompt small migrations, but for longer, more complex, repeatable tasks (think “codemods” that used to perform poorly) running the CLIs in a loop can produce incredible results.

The trick is to make the model work on one single thing at a time, stopping, verifying, and then moving on. This “loop” approach lets you chain many small, reliable transformations together without overwhelming the model or the codebase.

Miscellaneous / Tips and Tricks

• What about MCPs?
  Use them only when needed (e.g., Chrome/Playwright for frontend code, Context7 for documentation, etc.).

• What about Cursor Rules, Agents.md, Claude.md?
  Models are getting better at finding the right context themselves, but if they keep making the same mistake repeatedly, add the rule to the appropriate .md file. (There’s a handy GitHub Action that can be triggered during code review to update those files.)

• Voice Mode
  I started using Wisprflow more, but I still like typing so I can order my thoughts.

• Context Window
  You shouldn’t worry too much these days (Codex is very good, Claude has auto‑compact). I recommend starting a new session as often as possible to reset your context window—without losing context, of course.

• Automate repetitive tasks
  Claude Code supports slash commands and sub‑agents to automate things like push, commit, review, run tests, etc.

Caveats / Constraints – Working with Production Software

The way I use AI to code on a green‑field project differs significantly from coding on old/production codebases. Modern models can work effectively in large repositories, but there are constraints we should be aware of, and there are improvements you can make to the code itself that will increase speed and output considerably.

1. Spaghetti Code

• Large, unrelated sections of code bloat the context window, making the model slower and token‑inefficient.
• Fixes:
  • Reduce circular dependencies.
  • Encapsulate components behind clear interfaces.
  • Enforce a well‑defined architecture and module boundaries.

If your application is rotten, it will also rot your context.

2. To Rewrite or Not Rewrite

• When a model’s context window fills, it resorts to “context compaction.”
• The same principle applies to legacy codebases: once technical debt and outdated decisions accumulate, it can be more efficient to capture the intent, summarize the current state, and start fresh (often called a rewrite).

It’s never been cheaper to rewrite something!

3. Missing Verification Loop

• Models that cannot verify their own output need more steering and cannot work continuously.
• Human verification must be committed and saved (e.g., via tests, lint rules, type checking, or agent context) for future changes.
• Models are great at generating tests, but they do not replace true verification—the human decision that the system is correct.

4. Testing Chicken‑and‑Egg Paradox

• Non‑modular code is hard to test.
• Missing tests break the verification loop, producing code that is difficult to change and test.
• Solution:
  1. Write human‑verified tests and commit them.
  2. Close the verification loop so new code and improvements can be added safely by both humans and coding agents.

5. Code Is Not the Bottleneck Anymore – Verification Is!

“If your pull request doesn’t contain evidence that it works, you’re not shipping faster—you’re just moving work downstream.” – Addy Osmani

• Agents can generate reliable code quickly, but ensuring correctness is now the bottleneck.
• Major culprits:
  • Manual code reviews.
  • Manual testing.
  • Slow automated test suites.

Speeding up these areas (e.g., by parallelizing tests, using faster CI pipelines, or improving review tooling) will increase the velocity of shipping code to production.

6. The Kitchen‑Sink Paradox

• Models behave like humans: if they see a dirty sink, they’ll just add another plate on top.
• They will not refactor or improve code unless explicitly instructed.
• Whenever you make a change, also ask the model to ship an improvement to that part of the code—especially around verification (tests, type annotations, lint rules, etc.).

7. Risk of Change Is a Limiting Factor

• Code is cheap now; we should experiment more and not shy away from significant changes just because the code is “old” or complex.
• The main obstacle to large‑scale changes is the risk of regressions.
• Tight verification loops (comprehensive tests, static analysis, continuous integration) are the key to mitigating that risk.

Even with excellent testing practices (which are rare), more code and more changes mean more bugs and more risk—businesses need to accept and manage that risk.

Quick Checklist for Production‑Ready AI‑Assisted Development

By addressing these constraints and adopting the checklist above, you’ll make AI‑assisted development on production codebases faster, safer, and more maintainable.

Conclusion

You are not behind—keep it simple, just give it a go, and improve every day. It sounds better when it comes from Sunil:

“You are not behind, keep it simple, just give it a go and improve every day…”

Recommended Reading

• Boris Claude Code Setup
• Where Good Ideas Come From for Coding Agents
• Just Talk To It – The No‑BS Way of Agentic Engineering
• How to Ralph
• AI Writes Code Faster. Your Job Is Still to Prove It Works