🚀 Getting into the Flow
Exploring Codex and GitHub Copilot helped me approach unfamiliar Python projects differently.
Without knowing much about a large repo, I could still trace the logic, fix issues, and experiment safely.
🧩 What Codex Helped Me Do
- Identified and fixed a bug in a repo I hadn’t seen before.
- Understood and tested FastAPI endpoints by inspecting generated code and responses.
- Built a computer-use agent with open source agents2.
Codex supported quick code exploration and iterative debugging — especially when working across multiple files or APIs.
⚙️ How Copilot Fits In
GitHub Copilot integrated smoothly with the IDE setup, allowing me to:
- Run and test code directly,
- Execute API calls from the console,
- Use inline scripts (
ps1,sh, orcurl) for validation and quick checks.
I even asked the Copilot Agent to reorganize the current solution — and it handled it neatly.
Asked Copilot Agent to help test and automate build scripts — it organized the integration suite, executed shell runners, and verified the build successfully.
Asked Copilot Agent to help me clean up a merged Git branch. The task was simple and it completed it.
🧩 Testing Chaos: Fixed with Docker
While testing APIs and running integration checks from the same IDE instance, the inline commands often froze or failed to complete.
The API process and the test commands shared the same runtime session — once the API started, the console could not process further commands.
This behavior appeared on both macOS and Windows.
macOS handled it slightly better by creating new process instances for test calls, but it wasn’t consistent — Windows, meanwhile, often locked the terminal completely until the process ended.
✅ The Reliable Fix – Docker
Running the server inside Docker isolated the environment completely:
- The MCP or API runs in its own container.
- Test commands execute independently from another terminal or container.
- No more port conflicts or blocking sessions.
This setup worked the same way on both macOS and Windows — predictable and stable.
🧩 Reference: Docker Testing
I asked Copilot to test the integration suite via Docker — and learned that specific prompts matter. Without clear context, Codex or Copilot might rebuild the entire project or run unrelated modules inside the same container. Prompt clarity keeps your Docker runs focused and faster.
Reference images for Docker-based testing:
Testing results:
💬 Reflection
While working with Codex and Copilot, I noticed they sometimes go beyond what’s asked —
writing a quick README, fixing commented-out code, or even generating unit tests automatically.
Fixing the commented-out code — refer below:
Good in one way or another, but it’s better to focus on completing the business logic first and let these automated helpers refine things later.
If you see it drifting or not doing the intended action, try re-prompting or being more specific.
Better prompts often mean better control — though sometimes, letting it run freely shows how it “thinks.”
There’s definitely something about vibecoding — it made me code longer hours without realizing it.
Probably off the vibe or what... 🤷♂️💻
These visuals represent snapshots from my experiments — showing how each tool played a part in exploration, debugging, and learning.
✨ TL;DR
🧠 Codex helped me read and fix unfamiliar code.
⚙️ Copilot made testing and execution flow easier.
🐳 Docker kept everything clean, isolated, and predictable — across macOS and Windows.
💡 Tip: Try not to clear the chat — it warns you, but doing so can reset the modified repo state and you’ll lose your changes. You’ll need to re-prompt or rebuild the context again.
Top comments (0)