Context Engineering Across AI Code Generators

TL;DR: The evolution of code generators from desktop AI apps to cli-based tools represents a fundamental shift in context engineering. While writing code using the claude/openai/gemini desktop apps require manual context management, CLI tools handle it automatically, letting developers focus on the task rather than the tool.

I’ve spent the last month living in three different cli-based coding environments (cli-ai-code), and I’ve come to a realisation: the future of AI-assisted development isn’t about which model you use—it’s about who controls the context engineering. And increasingly the code generators are getting better.

My journey started last summer, where many developers begin: Claude’s desktop app (claude). I’d carefully curate which files to share, write detailed code guidelines, and manage every aspect of the conversation. The process felt like conducting an orchestra—I was constantly directing attention, summarising when contexts grew too long, and asking for diffs instead of full file updates to manage tokens.

This approach worked, but it was exhausting. Building this very website using Claude’s desktop app taught me just how much overhead manual context management creates. Every conversation turn required decisions about what to include, what to summarise, and what to leave out. The copy-pasting between the app was fun, but the slowest part of the process. You can read about that journey in detail, but the key takeaway was simple: I was spending more time managing the AI than should be required, it was also obvious that hte IDE integrations that were emerging would be a better option.

Windsurf, Cursor, and GitHub Copilot offered a different experience. These tools live where developers already work, felt like the perfect solution. No more copy-pasting, no more context curation—just code completion and error fixing right in my editor. The agentic mode was a game-changer, because the editor could now look at the workspace or additional files to understand the context of the code. The manual context engineering for the IDEs is improviong each week, since early this year, vibe-coding has been the norm for many. My experience with the IDE-based tools has been positive, but a bit of a hit and miss, especially with React, where sometimes missing a file or a dependency can cause the codegen to duplicate that code. Again, this is not an issue long-term, as context windows are becoming larger and information in the .cursorfiles folder becomes automated. Overall – you need to ensure the agent has access to the correct files, have proper documentation and if your repository is large, you’re essentially doing the same curation work as with desktop apps, just with a different interface. The tension between giving complete control to the agent and maintaining oversight never quite resolved for me. These IDEs exceled at micro-tasks—completing, fixing errors and bugs, writing test cases (I wrote a lot of the tests!)

Recently, since Claude Sonnet 4.0 with code release in May and re-release of codex, I’ve leaned into using cli-ai-code – and frankly fallen in love with them. The experience is so much better than the IDE-based workflow, and because the ux is so constrained, you have to completely lean into the CLIs workflows, create and keep the claude.md, readme.md, ./docs/ folder up to date. Also the /compress and /clear commands forces you to think a bit more about the context that the CLI has build insofar for you, but the CLI for the most part is taking full responsibility for context engineering. There aren’t toggles for which files to read. There’s no manual curation. You give it a task, and it figures out what it needs. This complete delegation initially felt uncomfortable—I was used to being in control. But the results spoke for themselves.

The UX advantage of cli-ai-code surprised me. Unlike editor-based AIs where code constantly competes for your attention, the terminal provides focused feedback. You see the thinking steps, the greps, seds and awks, glob in/out, regexs,the task checklist and progress updates. When the AI is working, you’re not distracted by syntax highlighting or autocompletions. Your sole focus remains on the terminal, on the plan, on the outcome. More importantly, cli-ai-code offer clear intervention points. You can stop midway if the approach seems wrong, or let it complete and then provide corrective guidance. This isn’t the black box of agent mode in IDEs—it’s transparent, iterative development. Similarly, the claude.md and .cursorfiles folder can contain detailed project specifications, coding standards, and architectural decisions. But this is the trade-off: IDE tools provide more granular control over context at the cost of requiring explicit creation and maintenance of that documentation.

The OpenAI Codex Exception: Asynchronous Development: codex deserves special mention because it operates differently. I use it in what I call "away-from-keyboard" mode. The workflow is unique: provide a complete task specification—almost like a dev/product spec—and openai spins up a container in the cloud, plans the implementation, executes it, and returns a pull request. This approach has proven invaluable during commutes or when travelling with intermittent connectivity. The key is being upfront about design and architecture because each conversation spawns a fresh container build. There’s no iterative back-and-forth; you need to get the specification right upfront.

I recently used this approach to build an entire phone number transfer system for Daily. The entire project was "vibecoded"—I provided the requirements, claude/codex handled the implementation, and I reviewed the resulting PR. Similarly, a queueing system I needed was entirely written through cli-ai-code without me writing a single line of code manually. I am currently trying out gemini’s CLI codegen as well.

Context Engineering: The Real Differentiator

The progression from desktop apps to CLI tools represents a fundamental shift in how we think about context. In desktop apps, context engineering is explicit and manual. You decide what the AI sees. In IDE integrations, it’s semi-automatic but limited to open files and explicit selections, I think they are getting better with workspace access. In CLI tools, it’s completely delegated to the AI.

This delegation initially feels like losing control, but it’s actually gaining leverage. When I use cli-ai-code, I’m not thinking about which files to include or how to structure my request to fit within token limits. I’m thinking about the problem I want to solve. The tool handles the complexity of understanding my codebase, finding relevant files, and maintaining context across operations. If it doesn’t have access to the relevant files, it will ask for them.

Looking forward, the shift from manual to automatic context engineering represents more than a tooling change—it’s a fundamental rethinking of the developer-AI relationship. As these tools mature, I expect we’ll see even more sophisticated context understanding, better intervention mechanisms, and smoother workflows. For developers still managing context manually, I encourage you to try CLI-based tools. The initial adjustment period is worth it. You might find, as I did, that letting go of context control actually gives you more control over what matters: solving problems and building software.

The command line, that venerable interface we’ve used for decades, has found new purpose. And honestly? It feels like coming home.