Ask HN’s LLM Coding Flow Debate

The Ask HN: Is anyone experimenting with different ways of using LLMs for coding? debate is about whether AI coding is stuck in a prompt-response loop, not whether models are useful. The useful answer is: better context plumbing helps, but flow only comes back when the work has clear contracts and fast verification.

A codex cli mcp setup and a codex mcp server can reduce context-chasing in OpenAI Codex, OpenAI’s coding agent, but they do not remove the need to steer. MCP is an open protocol for connecting AI tools to external systems and context sources through bounded servers.

See why the thread hit a nerve

The Hacker News post started with a feeling many developers recognize: coding with an LLM can feel like riding a bicycle that keeps braking. You ask, wait, review, correct, and ask again. The author said they use Claude Code, Anthropic’s coding agent, and Codex, but still could not enter the same flow state they get when writing code by hand.

That is a useful complaint because it is not model-doomerism. It accepts that the tools work. The frustration is with the interface: chat, review, prompt again, context drifts, repeat.

The author wondered whether the tab-completion model might be directionally better than the prompt-response loop. That matters because tab completion preserves the developer’s rhythm. You stay inside the file, reject or accept small moves, and keep the mental stack warm.

The trap is pretending this is only a UX gripe. It is also a workflow architecture problem. If the agent has vague intent, missing repo rules, and no tight verification loop, even a nicer interface becomes a faster way to produce uncertain code.

Take the spec-first side seriously

One strong reply in the thread argued for less external orchestration, not more. The claim was simple: current top models are already good at planning, so spend energy on clearer specs. Define the intent, input/output contracts, invariants, edge cases, and when the model should ask a question instead of guessing.

That view is boring in the best way. In a real repo, it sounds like a feature note for payment retry behavior: retry only idempotent operations, never duplicate a ledger entry, return a typed failure after three attempts, and include a test for timeout plus declined-card paths.

For Codex CLI work, that spec belongs close to the code. A small AGENTS.md can tell Codex what matters before the task prompt gets clever:

# AGENTS.md

- Do not change public API shapes without updating contract tests.
- Prefer small commits that keep the test suite green after each step.
- For payment retry code, preserve idempotency keys and ledger invariants.
- When behavior is ambiguous, ask before editing.

The trap is turning specs into a second implementation. A good spec removes ambiguity; it does not narrate every line the agent should write. If your markdown takes longer to maintain than the code, you have moved the bottleneck rather than fixed it.

Give context plumbing its due

Another reply described building a JSX-style templating language to manage context, branching, and recipes automatically. That is a real pain point. Once a task crosses several files, most of the work becomes context piping: which docs, which examples, which constraints, which previous attempts, and which output shape.

This is where MCP is interesting for Codex workflows. Instead of pasting issue text, schema snippets, and release notes into a prompt, you can give the agent a bounded way to fetch the right context. The boundary is the important part: read-only documentation and issue metadata are very different from write access to production systems.

A concrete example: let Codex read internal API docs and GitHub issue metadata, but not mutate tickets or touch secrets. Then put the rule in AGENTS.md so the boundary is visible in code review:

# MCP boundary

- Use MCP docs context for API examples and issue details.
- Treat MCP output as reference material, not source of truth.
- Do not call write-capable tools unless the task explicitly asks for it.
- Summarize any external context used in the final handoff.

The trap is believing plumbing equals flow. A well-scoped MCP connection can remove clipboard work. It cannot decide whether the requested change is actually the right product behavior.

Notice what autocomplete envy reveals

A related question in the thread asked whether there are autocomplete models near the quality of frontier chat models. The question is sharper than it looks. Developers are not only asking for smarter code; they are asking for code at the right granularity.

Chat agents often work in chunks: plan, edit, explain, wait. Autocomplete works in sips. It keeps you in the source file and gives you a reversible suggestion before your attention shifts away.

The best version of the prompt-loop side says larger chunks are worth it for cross-file work. The best version of the tab-model side says flow is lost when every small decision becomes a mini project manager interaction.

The trap is making one interface carry every job. A Codex agent is a good fit for mechanical cross-file changes, test generation, migrations, and boring cleanup. Inline completion is better when you are exploring a tricky abstraction and want your hands to stay on the code.

Test the argument on one real change

Do not settle this debate by arguing about agents in the abstract. Run one small local experiment on a change your repo actually needs. The goal is not to prove that chat, tabs, specs, or MCP wins forever; it is to find where your flow breaks.

Prerequisites:

• One small issue that touches 2–5 files.
• A passing baseline test command.
• A short AGENTS.md with repo rules.
• Optional read-only Codex MCP access to docs, issues, or schema context.
• A place to record time, interruptions, and review notes.

Step 1: pick a change with a real acceptance test. Choose something like adding a validation rule to POST /invoices or updating a deprecated API call. Avoid huge refactors. You want a change small enough to finish twice, once with a prompt-loop workflow and once with a more prepared workflow.

Step 2: write the contract before prompting. Capture intent, inputs, outputs, edge cases, and the exact verification command. This is the spec-first argument at its strongest, and it keeps the model from inventing success criteria halfway through the task.

Step 3: add one bounded context source. If you use a Codex CLI MCP server, make the first server read-only and boring: docs, issue metadata, or schema reference. If your Codex CLI build exposes MCP management commands, run the codex mcp list command to confirm what is connected before the task starts.

Step 4: ask Codex for a small patch, not a saga. A good prompt is closer to a handoff than a wish: mention the issue, the contract, the files likely involved, and the test command. Ask Codex to stop and ask if behavior is ambiguous.

Step 5: review the diff outside the chat transcript. Read the patch as if a human teammate sent it. Check contract fit, deleted behavior, test coverage, and whether any MCP context was used as evidence rather than copied blindly.

Step 6: verify with one command and one receipt. Run the baseline test command, then ask Codex to summarize what changed, what was verified, and what remains risky. If the summary cannot name the contract and the test result, the workflow is still too mushy.

This experiment fits naturally inside the related training topic. If the change touches sensitive paths, read OpenAI Codex Sensitive Files Issue before wiring external context into the loop.

Keep both sides in one table

Use this table as the copyable artifact. It keeps the Hacker News argument honest without forcing a grand theory.

Question	Spec-first answer	Context-plumbing answer	Local experiment
Why does flow break?	The task is underspecified.	The agent lacks the right context at the right time.	Count how many times you stop to clarify behavior versus paste context.
What should change first?	Write clearer contracts and repo rules.	Add bounded access to docs, issues, schemas, or examples.	Try the same issue with only AGENTS.md, then with one read-only MCP source.
What is the risk?	Specs become bulky and stale.	Integrations hide bad assumptions behind tool calls.	Review whether failures came from unclear intent or wrong context.
What proves it worked?	The patch matches the contract with fewer corrections.	The patch uses correct repo facts without copy-paste.	Compare review time, test failures, and number of prompt turns.

Small experiment receipt:

## LLM coding flow experiment

Issue:
Workflow tested: prompt-loop / spec-first / Codex MCP
Files changed:
Contract written before coding: yes / no
MCP sources used:
Prompt turns:
Times I had to paste missing context:
Verification command:
Verification result:
Main flow break:
Would I use this workflow again for this task type?

The table will not tell you which tool is best. It will tell you which part of your own workflow is breaking: intent, context, interface, or verification.

Common questions

• Do I need a codex mcp server to improve coding flow? No, you do not need a codex mcp server to improve flow. Start with a clear AGENTS.md, a short contract, and one verification command; add MCP only when you repeatedly paste the same docs, issue details, schemas, or examples into Codex CLI.

• Is Codex better for prompt-loop work or autocomplete-style work? Codex is better suited to explicit agent tasks than pure autocomplete-style flow. Use it for cross-file edits, tests, migrations, and reviewable patches; keep manual coding or editor completion for delicate design work where you want every suggestion to arrive at cursor speed.

• What should I put in AGENTS.md for this kind of experiment? Put durable repo rules in AGENTS.md, not task chatter. Good entries include test commands, architectural boundaries, public API constraints, security rules, and when Codex should ask before editing; task-specific acceptance criteria belong in the prompt or issue note.

• How do I know whether codex mcp is helping or just adding noise? Codex MCP is helping when it reduces pasted context and improves factual accuracy without increasing review risk. Track three numbers for one issue: prompt turns, times you pasted missing context, and test or review failures caused by wrong assumptions.

• Should I trust the model to plan instead of building wrappers around it? Often, yes, but only inside a tight boundary. The strongest argument from the thread is that models can plan well when intent and contracts are clear; the caveat is that external context and verification still need explicit limits.

Best ways to use this research

• Best for: deciding whether your AI coding friction is caused by vague specs, missing context, or the chat interface itself.
• Best first artifact: a small AGENTS.md plus one issue contract and one verification command.
• Best comparison angle: run the same 2–5 file change with spec-only context, then with one read-only MCP source.
• Best Codex Workshop takeaway: treat Codex CLI workflows as feedback loops, not magic prompts; every loop needs intent, context, patch, review, and proof.

Further reading

• OpenAI Developers — Codex CLI
• OpenAI Developers — Codex slash commands
• Model Context Protocol — specification

Try one issue, not a philosophy

Pick one real change and measure where the loop breaks. Then improve that one boundary before you add another tool.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.