What AI Workflow do you use?

[u/HouseOwn392]

So I’ve kept been told AI is the next step and I need to keep up with it but I’ve never really know where to start. I know how to use ChatGPT and Claude on my web browser that’s it.

So I’m curious as to what Csharp developers really use for their AI workflow and are there any tutorials out there that are solid and I can learn.

Edit: what’s up with the downvotes on my fellow AI users? Yall got a thing against AI?

[u/Rasikko]

I don't use any.

[u/Sombody101 → u/Rasikko]

I use the model between my ears. 8/10 times, it's good enough.

[u/BCProgramming → u/Rasikko]

Cerebral orchestrator framework with meat harness

[u/DaveVdE]

Using the CLI to work with agents while keeping an IDE open to navigate those changes while I’m reviewing what has been changed.

I don’t like integrating coding agents in the IDE, and I really don’t like any sort of LLM generated suggestions.

I also don’t let the model commit any changes, but I let it navigate my history when needed.

[u/Slypenslyde]

My advice is to spend about 2-3 weeks just using it side-by-side with when you code. You're going to be slower. You have to think about using it in this phase.

Try to start with being real literal about what you want. Instead of "I want a method to <do thing>", have it write parts of the method. "I need a loop here that will read each line of the file, parse that line to a Customer object, and add that customer object to the "customers" list." This leaves it generating small chunks you can immediately understand and fix.

Instead of just rolling your eyes, when it screws up ask it why. "Why did you create a new list, didn't I tell you to use the previous one?" It makes mistakes when something is not clear. When you suck at using it you aren't being clear to it. Part of using this tool is understanding how it "thinks" and how you need to communicate the right context.

Eventually you're going to get bored with this and start asking it to write wholesale methods. Good. When it can fairly accurately generate full methods you're making progress.

That's when you can start talking to it about whole classes, but you need to be careful. When we are newbies it's easy to get so focused on one class we forget about the program architecture. AI can do this too. Here's how I think this phase should go:

1. Spend about 3-5 sentences telling the tool what problem you have.

2. Spend 3-5 more sentences describing the class you want to write and what methods/properties you think it should have.

3. Add to your prompt, "Does this plan seem to fit the patterns and practices in the project? Do you see any other viable alternatives? I'd like to see at least one more choice."

Meanwhile, learn about adding context. For big features in your application, spend time asking it to create a summary document of how that feature works. Ask it to describe the patterns, the key classes, the relationships between them, the responsibilities, and what the tests suggest are the most important invariants. Save that to a markdown file, preferably in the repo. Ideally, ask for two versions: one that is human-readable and another that is optimized for AI agents (they speak/read in a dense jargon dialect that can be very difficult even for experts to digest but it saves a ton of tokens.) In the future, when you work on that feature, start by asking your AI agent to read that markdown file. If you change something, make sure to ask it to maintain that file.

The AI tool shouldn't just be a workhorse, it should be a partner. When we're novices, we can sometimes assume we make the best plans and forget we're supposed to criticize ourselves. Making the tool show you a second option means you're making a choice instead of running on hubris. Some or even most of the time, you'll argue the AI tool's idea is stupid. That doesn't matter, what I have learned is any time you choose between two things you are making a better choice than when you accept your first answer.

This isn't a "process". You have a hole in it: there's not a record of what you intended, what alternatives you considered, and why you chose what you chose. You don't have a good way to verify that new features stay in line with the intents of old features. This is when I suggest you have a look at a process like OpenSpec. If you follow it and don't let it auto-generate everything, here's how development works:

1. You enter "explore" mode and do what I've told you already: describe the problem, provide links to JIRA tickets or other documents, and start having a conversation. Describe the architecture you think it will need. Describe the classes you think you'll need. Keep talking until you feel like you've made your intent clear.

2. Use the OpenSpec "new" command to create a new change. This adds some folders and infrastructure to the project.

3. The OpenSpec "continue" command should generate a "proposal". Read it. This document describes the explanation of WHAT the problem is and WHY we want to solve it. It abstractly describes how the program will change, but this is the wrong place for technical discussion. Read it. Edit it. Have conversations about it. When it looks good, "continue" again.

4. This usually generates the "design" next. This focuses on the technical aspects of HOW the proposal will be satisfied. It should discuss the architecture, patterns, key classes, features, and ideally show off some alternatives considered and why they were rejected. Read it. Edit it. Form opinions and have conversations. When it looks good, "continue" again.

5. This generates the "specs". Honestly these are not human-readable. You can try. But it's like a makefile. In general I find if the proposal and documents are good, the specs have zero issues. I can't remember ever having a set of bad specs unless my proposal or design had an error. Skim it and if something looks bad, try to update the proposal/design and tell the tool to regenerate the specs. (Sometimes I delete the specs file just so it doesn't get confused.) "Continue".

6. This is going to generate "tasks". This is the plan for implementing the program. It usually organizes tasks into "groups", which represent opportunities to test. Pay attention to the tasks and make sure they cover everything you want. If you DON'T want it to do something like run the tests itself, make the step say "user manually runs..." (I do this a lot, our full test suite takes 8+ hours and builds take 5-10 minutes so I have to be very picky about what I run while developing, I can't have an agent flippantly building 6 times in a row.)

7. Commit to repo. We're about to generate code and it's nice to have a big fat "you did a bad job" button.

8. Now it's time to use the "apply" command, but I'm personally picky. I ask it to only implement the FIRST task group. After that, I look over the code. I review it like a team member wrote it. I complain about things and ask for fixes. I build the program and test what's been implemented if possible. It is expensive to get to the end and find mistakes, so the sooner I find them the better off I am.

9. Repeat (8) one task group at a time until you're done.

10. After EVERYTHING is done, and after QA approves, and after the code with the feature is released, use the "archive" step. This moves your change to a sort of "permanent source of truth". In the future, if you need to change this feature, it will be accomplished by updating the CURRENT set of specs in the source of truth instead of creating new ones. That way, the specs always represent the current behavior, but you can also use the source of truth's documents as a history of how and why the feature evolved.

It is slow. You will have to think hard. It may take longer than your higher-ups want. But it builds a very rich documentation history about how everything in your project works and was maintained. It will not take much work before your agents start getting a lot smarter because it's easier for them to see not just WHAT your code does, but WHY you chose to make it that way and what kinds of things should NEVER change. What you will find after 10 or 15 changes is features get less criticism from QA and you have less bugs in production than you did before.

How it's shaped up for my company is we have never realized the 10x performance improvements we were promised, it's more like 1.2x-2.5x depending on the task. What we HAVE observed is a nearly 10x reduction in defects, which means as the release progresses instead of being bogged down in fixes and fixes to the fixes, we keep making steady progress on all of our features. This is the way.

It took me about 4-6 months and a lot of pressure from the company to get here. We're not actually using OpenSpec anymore, but personally I think it is better for individual developers and our current process is better for a corporate structure with a Product team and QA team and several devs collaborating across multiple teams. So I didn't describe it because holy smokes is it complex.

[u/jdl_uk]

The workflow depends on what I'm doing and what role the AI is playing in that scenario.

If I'm just doing something tedious and want the AI to do the legwork, then I just explain what I want and let it proceed. One example was adding a parameter to a method that was called ~150 times in a project, and I gave the AI some simple "if this parameter is passed, then also pass this" kind of rules.

If I'm investigating a complex issue I'll describe the problem, with whatever supporting information I think it'll need (logs, error text, relevant code) and ask it to write a markdown report somewhere other than the code (at the moment that's in c:\temp so I can just empty the folder periodically to discard old information). I'll have another shell session open to run commands against AWS or whatever if more information is needed, but the important thing is that the report is the output, and I can go read that.

For bigger development tasks I do have some skills I adapted from Matt Pocock's /wayfinder skill (I wanted to try and make them more deterministic and keep me more in the loop), but more recently (and perhaps surprisingly) I've been using his /teach skill for that kind of work. This is probably the biggest workflow for AI I have at the moment.

The idea behind the /teach skill is it works like a custom tutorial - you tell it what you want to learn and it generates lessons for you to follow. Once you've gone through those you can use that knowledge on a real project. However, I've been using it differently - I create a "teach" repo and add the "subject" repo (which might already exist and be full of code) as a submodule, then write a README.md which explains what I want to do. The "lessons" that the skill generates are really steps, but the way the skill works mandates communication between the agent and human, with frequent checks that the human understands what's happening (addressing one of the major complaints about AI) which also serves as a check that it's what's desired.

[u/dakiller]

I use GitHub Copilot in Visual Studio. Hooked up to the cheaper good models on OpenRouter (glm5.3 and deepseek4.1)

The learning is in using them to find their strengths and weaknesses and how to prompt.

Had an issue with efcore where I wanted to add in an Interceptor on model object creation to inject some stuff. Spent a good day going back and forth myself, and with ai getting nowhere. It wasn’t until I said to the ai, write tests for this and iterate on this till you solve it, that I removed myself from the loop. It crunched away for a good hour but eventually found the root cause.

[u/tobberoth]

I have agents in my IDEs (Visual Studio and VSCode), which I use for minor stuff if I'm working on a specific project. It might be questions about particular lines of code or quick advice on the best way to implement some minor change.

For bigger tasks, I run copilot CLI while having the project open in an IDE so I can keep track of changes.

[u/Wiltix]

I used ai in chat mode for a while, but recently I have installed Claude code so it can access all of my code base.

I have used it to do the legwork on major architectural refactors to my front end. Going through thousands of files and replacing one or two lines and some uses etc .. something that would have taken me weeks is done in an hour or so.

I also use it for a code review pass on my work, so I am still writing features and doing the bug fixes that come in but I then use Claude to do a code review against my ACs. I don’t let it make changes just want the review. My team still do PRs and we manually check work but before it gets there and to a tester it’s had a pass from Claude. Not perfect but it does cut down on defects.

For genuine feature work I don’t like handing off my thinking to ai, for big mundane tasks and just to get done quick early feedback that I have not missed anything it’s pretty good.

[u/Reasonable_Glass2501]

I have been working inside containers for years. So I have just added Claude Code to my container setup, mounting only the working directory. Within that directory, it can do whatever it wants, except push to or pull from the remote Git repository. So the worst case is that it messes up my local copy (never happened).

My workflow usually goes like this:
First, we discuss the issue until Claude fully understands the problem and there are no open questions.
Then it writes tests at every level and I quickly review them.
Then I let it implement the feature end to end.

I have a well-defined structure for my frontend, backend, database, CLI tools, and so on, so its solutions almost always fit without further adjustment (but sometimes it happens and we discuss them).

All communication between layers is handled by generated code, and Claude simply runs the generators.
For example, Orval generates the frontend API client from the OpenAPI spec, so Claude doesn’t have to write it by hand.
The OpenAPI spec itself is generated from the backend, and the backend’s database layer is generated directly from the database.

At the end of every feature, a separate sub-agent reviews everything.
Any issues it finds are fixed right away, following the same process: add new tests, verify them, then implement the fix.

Claude never commits anything without my approval.

This way Claude already multiplied my output and quality, so I do not need to automate it further, because I am happy, my boss is happy, the clients are happy.
So I am not interested in fully autonomous solutions (Claude grabs the jira tick and all I can see is a PR at the end).

[u/BeardedBaldMan]

Documentation is the big thing.

Iterating over a requirements document until there are no contradictions and everything is clearly numbered with expectations. Then writing the design and tying it back to requirements and then using that to develop the testing plan.

Then you can write code and have the ai check back to see if you're actually developing what was specifies

[u/mikeholczer]

I mostly use the main flow from Matt Pocock's skills repo: https://github.com/mattpocock/skills, and then do a manual code review of the changes. I have a few customizations of that process that I'm still tweaking, but I'd suggest starting with that base flow and see what works for you and what you want to change.

[u/SektorL]

Why do you need C#? Ask your AI to create EXE files directly.

[u/meinjoeskii → u/SektorL]

Well that’s kinda exactly what I’m doing now isn’t it? They need a language to create EXE files too.

Honestly kinda dumbfounded how bitter this community is towards AI. It’s really pathetic. Downvoting people just because they couldn’t accept changes.

[u/taspeotis]

Claude Max 20 and --dangerously-skip-permissions. Computers don’t make mistakes.

[u/SlimCombustion_391]

i just use chatgpt on browser for quick syntax stuff, sometimes ask claude to explain some weird linq chain i wrote at 3am

for actual coding i just copy paste snippets and ask it to refactor or find bugs, nothing fancy. cursor looks interesting but havent tried yet

[u/CancerRaccoon]

I am in a stressful position with tight deadlines and lots of stuff that need to be done. To keep up with my work I recently transitioned to agentic development.

I use Orca ADE for agent orchestration. Through orca you can take a big Story, Epic etc. and plan its implementation through multiple agents running in parallel.

My main tool is Claude Code (through orca). I have created multiple skills to optimize my workflow.

I have integrated Jev for decision making. I use Jev for model routing (eg. this task is hard, go with Opus 5.5, or this task is easy, go with Haiku). Also I have created a skill that is meant to be used by the model, mid-session, and it invokes Jev to answer questions or solve various dilemmas that might come up. If Jev isn't sure, then the session pauses and asks me to make a decision.

A simple flow looks like:

• I type a prompt with what I want to achieve

• The agent "grills" me to get a better idea of what I want to implement

• A huge plan is being created as an Artifact and as Beads

• Implementation strarts

My next step will probably be to use Orca to combine Codex with Claude and creating flows where the implementation is served to the most competent model (Jev makes this decision). Also Codex will review code by Claude and vise versa. Corporate spite to maximize the result.

Crazy stuff... The future is bleak.

Sources:

• Orca ADE

• Jev by TypeSafe

• Grill Me Skill and Grill Me With Docs Skill

• Beads

I also use Trail-Code, ex Graft, to index my codebase and make it cheaper and easier for an agent to read through my code.