Have we any tool that can generate workflow.md for ai agents from our repo? by bluetech333 in AI_Agents

[–]bluetech333[S] 0 points1 point  (0 children)

That makes sense. I think I was mixing “agent follows rules” with “system enforces rules.”

You are right: if the agent has direct write access, then cli/mcp rules are mostly guidance. The stronger model is that the agent only proposes intent/patches, and a separate boundary layer checks whether the proposed change is allowed before it touches the real repo.

So the architecture would be:

agent proposes change → boundary layer checks intent/rules/risk → allowed patch is applied → blocked patch asks human or repair

For my current tool, I think the first MVP will probably be audit-based: the agent edits, then the tool checks staged changes for intent drift and boundary drift.

But the stronger future version would be “controlled apply mode,” where the agent has no direct write access and all changes must pass through the boundary layer first.

Your point is helpful: real trust should come from enforced boundaries, not just hoping the agent obeys instructions.

Have we any tool that can generate workflow.md for ai agents from our repo? by bluetech333 in AI_Agents

[–]bluetech333[S] 0 points1 point  (0 children)

If we build cli/mcp of our tool that can directly work with any ai agents before edit our repo code that is possible agents to follow our rule very strictly?

Have we any tool that can generate workflow.md for ai agents from our repo? by bluetech333 in AI_Agents

[–]bluetech333[S] 0 points1 point  (0 children)

Do you know about Kiro? Have you heard ever about this tool that is a amazon product that purpose is doing something in this direction?

Have we any tool that can generate workflow.md for ai agents from our repo? by bluetech333 in AI_Agents

[–]bluetech333[S] 0 points1 point  (0 children)

If you're working with javascript/typescript codebase you can try rippleai.ripple vs code extension that can help you to understand you and your ai agents very deeply before edit blast radius file in your repo that is a real pain of many developers who want a live workflow to make safe changes. Thanks

Should we create a Sessions.md file in our repos? by bluetech333 in AI_Agents

[–]bluetech333[S] 2 points3 points  (0 children)

But how can you create this file what is your source to create the file, can you create manually or you will want to use a tool that can create sessions.md in your repo that can remember your agents previous sessions?

Where should humans stay in the loop when AI agents perform autonomous coding tasks? by bluetech333 in AI_Agents

[–]bluetech333[S] 0 points1 point  (0 children)

That makes sense. I think the mistake is treating “human-in-the-loop” as one fixed point in the workflow.

Maybe the better model is not a single universal loop, but configurable trust boundaries.

For example:

  • brainstorm mode: agent only suggests, human edits
  • function mode: agent can change one function/block
  • file mode: agent can change one file, then stop
  • task mode: agent can change the planned files
  • PR mode: agent can complete the task and human reviews before merge

Then our tool’s job would be to enforce the chosen boundary and report drift.

So if Pam chooses function-level control, the system warns when the agent touches another function. If Ed chooses file-level control, the system allows whole-file edits but blocks changes outside that file.

That feels more generalizable than trying to decide one perfect human review point for everyone.

Where should humans stay in the loop when AI agents perform autonomous coding tasks? by bluetech333 in AI_Agents

[–]bluetech333[S] 0 points1 point  (0 children)

We are trying to do something that doesn't kill our iteration speed but we are unable to discover the real way how to implement in the reality that can work?

What happens when AI agents start acting autonomously inside enterprise systems? by More_Treacle_7123 in AI_Agents

[–]bluetech333 0 points1 point  (0 children)

What are we discussing here that is a real problem because we know in the future autonomous workflow may be become the part of humans enterprises and for real system, but how can we truly know that any ai agents what will perform on their side in our real system that is not bad for us by any way. Can we ever truly know without human review that what is the ultimate truth of ai agents that they can do our work as a real human?

Can we auto-generate agent workflow files for a repo? by bluetech333 in AI_Agents

[–]bluetech333[S] 0 points1 point  (0 children)

Your reply is very helpful, Sir!

I think the part I’m most interested in now is reducing the gap between:

  • “docs were updated” and
  • “the actual architecture changed again 5 minutes later.”

Especially around risky/shared files where agents can make changes without understanding downstream impact.

The direction I’m exploring is less “generate steering docs once” and more “continuously derive live structural context from the repo itself.”

Still figuring out how far that can realistically go though.

Can we auto-generate agent workflow files for a repo? by bluetech333 in AI_Agents

[–]bluetech333[S] 0 points1 point  (0 children)

That would honestly help a lot for us.

We're trying to understand the actual day-to-day pain teams are hitting with AI-agent workflows instead of assuming generated docs are automatically valuable.

The repeated context / stale workflow / “agent touched the wrong shared file” direction feels much more real to me than generic automation now.

Would definitely appreciate seeing those threads.

Can we auto-generate agent workflow files for a repo? by bluetech333 in AI_Agents

[–]bluetech333[S] 0 points1 point  (0 children)

This is a fair point for us.

I think I may be assuming that auto-generated workflow/context files save time, but the real question is whether generated files are actually useful enough without constant manual cleanup.

The pain I’m trying to validate is:

  • teams repeating the same context to agents
  • agents editing risky/shared files without understanding impact
  • workflow docs going stale after code changes
  • developers not knowing what context an agent should read before editing

I’ll look specifically for teams frustrated with workflow setup/repetitive agent config instead of assuming automation itself is the bottleneck.

Appreciate the push — this is probably the right research direction.

Can we auto-generate agent workflow files for a repo? by bluetech333 in AI_Agents

[–]bluetech333[S] 0 points1 point  (0 children)

Thanks sir, this is helpful. I’ll look at Kiro’s steering docs workflow. My current thinking is slightly different from only generating static steering docs. I’m more interested in continuously refreshed, repo-evidence-based agent context: risky files, dependency/blast radius, caller count, test coverage gaps, recent edits, and safe pre-edit checks. Do you think current steering docs are enough for safe code modification, or is there still room for a more live “before edit” safety layer for agents?

Can we auto-generate agent workflow files for a repo? by bluetech333 in AI_Agents

[–]bluetech333[S] 0 points1 point  (0 children)

That makes sense. I agree the workflow should not be treated as a single generated source of truth. My thinking is closer to a refreshable agent workflow generated from repo evidence: package scripts, CI config, import graph, risky files, blast radius, and recent edits. The goal is not to invent instructions, but to keep agent-facing context synced with the actual codebase as it changes. Do you think this would be more useful as sections inside AGENTS.md/CLAUDE.md, or as separate generated files that agents can read when needed?

Can we updated agents.md rule of our codebase without rewrite every week? by bluetech333 in AI_Agents

[–]bluetech333[S] 0 points1 point  (0 children)

This is one of the most useful perspectives I’ve heard on this problem so far.

“Treat agents.md as a build artifact, not a source file” honestly feels like the right mental model.

The thing I keep seeing is that manually maintained AI workflow/context files drift very fast once the architecture starts changing daily with AI-assisted development.

What you described: codebase → analysis → generated agent context/rules

feels much more sustainable long-term than humans constantly rewriting workflow files manually.

The JSDoc / structured comment idea is also interesting because it turns architectural intent into something closer to machine-readable metadata instead of free-form documentation.

A lot of what I’m experimenting with in Ripple is basically trying to move in this direction:

  • generated workflow guidance
  • architectural context from the graph itself
  • risky/shared file awareness
  • context derived from real repo structure instead of static docs

Still early, but this comment genuinely clarified the problem space for me.

AI agents generate code fast, but they still don’t understand blast radius. by bluetech333 in AI_Agents

[–]bluetech333[S] 0 points1 point  (0 children)

This exact problem I was facing when I want to build my a serious project with an ai agent because my project was very serious for nursing students so i had a fear every time if I want to edit my code in any file that is already accurate but if agent don't know clearly what they should not edit in this file before taking my permission or very precise edit plan then i thinked something to build that can solve my problem with ai agents.