How do you control code bloat when using Codex 6.1sol? My project is a mess after a 20k-line overnight run

[anstns]

Hey everyone, I have a question for the community: how do you control the amount of generated code when using Matt's skills?
After using it, I've found that the files are scattered everywhere, and the project directory structure is a mess. The number of test cases is overwhelming, and it keeps reinventing the wheel for business logic. Honestly, the project feels completely unmaintainable now.
I'm using the Codex 6.1sol model for development. Just yesterday, I had a single task: change the file-reading logic in the client, node, and gateway programs to load from the network, and add a feature for the node to report its configuration usage. Surprisingly, it split this into 17 ticks and generated 20,000 lines of code in a single night!

[stanleys12]

The main lever is the approval step in /to-tickets. The skill is meant to stop and show you the whole breakdown before anything is published, so 17 tickets for one task should have been something you could cut down first.

Step 4 ("Quiz the user") has the agent present a numbered list with title, blocked-by and what each ticket delivers. It then asks "Does the granularity feel right? (too coarse / too fine)" and "Should any tickets be merged or split further?", and it iterates until you approve:

skills/skills/engineering/to-tickets/SKILL.md

Lines 42 to 56 in 59db609

	### 4. Quiz the user
	Present the proposed breakdown as a numbered list. For each ticket, show:
	- **Title**: short descriptive name
	- **Blocked by**: which other tickets (if any) must complete first
	- **What it delivers**: the end-to-end behaviour this ticket makes work
	Ask the user:
	- Does the granularity feel right? (too coarse / too fine)
	- Are the blocking edges correct: does each ticket only depend on tickets that genuinely gate it?
	- Should any tickets be merged or split further?
	Iterate until the user approves the breakdown.

If it went straight from your request to 17 published tickets, it skipped that step. Check the run. If the step did run, that's the point to push back with something like "this is two tickets, merge them" or "no new abstractions, reuse what exists".

Your task as described (load file reads from the network in three programs, plus a config-usage report from the node) could probably be 2 to 4 vertical slices. Each slice only has to be a complete, verifiable path that fits in one context window (

skills/skills/engineering/to-tickets/SKILL.md

Lines 29 to 36 in 59db609

	<vertical-slice-rules>
	- Each slice cuts a narrow but COMPLETE path through every layer (schema, API, UI, tests): vertical, NOT a horizontal slice of one layer
	- A completed slice is demoable or verifiable on its own
	- Each slice is sized to fit in a single fresh context window
	- Any prefactoring should be done first
	</vertical-slice-rules>

). That is a ceiling on size and does not set a number of tickets, so nothing in the skill pushes toward 17. You can tell it up front how many tickets you want, or tell it to merge slices until each one is a real demoable behaviour.

For "reinventing the wheel", step 2 of /to-tickets tells the agent to explore the codebase and to look for prefactoring first, so shared code gets extracted before the feature work (

skills/skills/engineering/to-tickets/SKILL.md

Lines 19 to 23 in 59db609

	### 2. Explore the codebase (optional)
	If you have not already explored the codebase, do so to understand the current state of the code. Ticket titles and descriptions should use the project's domain glossary vocabulary, and respect ADRs in the area you're touching.
	Look for opportunities to prefactor the code to make the implementation easier. "Make the change easy, then make the easy change."

). With three programs reading files, a good first ticket is one shared "load from network" module that all three then use. If the breakdown has no such ticket, ask for one in the quiz step.

For the test pile, /tdd is written as one seam, one test and one minimal implementation per cycle. It explicitly warns against writing bulk tests up front (

skills/skills/engineering/tdd/SKILL.md

Lines 32 to 37 in 59db609

	- **Horizontal slicing**: writing all tests first, then all implementation. Bulk tests verify _imagined_ behavior: you test the _shape_ of things rather than user-facing behavior, the tests go insensitive to real changes, and you commit to test structure before understanding the implementation. Work in **vertical slices** instead: one test → one implementation → repeat, each test a **tracer bullet** that responds to what the last cycle taught you.
	## Rules of the loop
	- **Red before green.** Write the failing test first, then only enough code to pass it. Don't anticipate future tests or add speculative features.
	- **One slice at a time.** One seam, one test, one minimal implementation per cycle.

). If you got hundreds of tests, tell it to test behaviour at the public interface only.

For the overnight run, I'd keep the approval step in and work the tickets one at a time, reviewing the diff after each. A 17-ticket queue run unattended means one bad early ticket gets built on by all the rest. The skills don't enforce a line budget, so the limits have to come from you at the breakdown step and from reviewing between tickets.

(I looked this up in the code with help from an AI assistant; the links are to the lines I checked.)