ICM for Software Engineering (Not Vibe Coding)

I'd be interested in hearing from experienced software engineers using ICM for serious, ongoing development, especially those who were building software before AI coding tools became part of the workflow.

I'm not looking for a vibe coding setup where an agent gets a feature request and runs with it. I'm interested in using ICM to support disciplined software engineering while preserving architecture, testing, standards, and continuity over time.

I already have a system, but it evolved organically and is more ICM-inspired than a coherent ICM implementation. I'm now trying to rethink it more systematically.

A few things I'd love to hear about:

How do you structure ICM for a greenfield software project?
How do you introduce it into an existing codebase?
How do you organize architecture, rules, strategy, milestones, decisions, and source code?
What does your feature lifecycle look like from scoping through implementation, testing, and review?
How do you scope context so the agent gets what it needs without loading the whole project?
What rules stay in context versus being enforced by tests, scripts, linters, or other gates?
How do you keep project state and decision history useful without creating stale or bloated context?
How does the ICM evolve after months of development?

I'm not necessarily looking for a complete workspace or one correct answer. Directory structures, examples, lessons learned, things that failed, or practical tips would all be useful.

I'm especially interested in setups where AI becomes part of a disciplined engineering process rather than replacing the engineering process with prompting.

19 comments

ICM for Software Engineering (Not Vibe Coding)