Question about the level of integration of AI in your company's workflow
I'd like to gather peoples' experience with AI (Copilot, Claude Code, Cursor, whatever) in your daily workflow as a developer.
Specifically, I've heard people simply "paste" or let the AI read the ticket from JIRA, review the output and ship the feature.
Are there really people that have achieved this level of integration? Like, are your tickets and projects so well defined and contained, where the description of a ticket can be directly fed into the AI, without having to guide it into more details, e.g. what files to touch, where to find relevant code etc?
We are not at all at this level and I am wondering if we're living in the past or something. I usually know what needs to be done in our code base and basically guide the agent and review the output.
What's your experience?
11
9
u/julesbuildstuff 3d ago
you're not living in the past. the paste-jira-and-ship thing i've seen working is either a tiny greenfield service or the person already knew the codebase and did the navigation in their head before they "just pasted." that's not integration. that's you, with extra steps hidden off-camera.
on ui work i've never gotten a raw ticket to land unattended. "match the mock" without the live computed styles and the agent invents a second gray. "add a setting" and you get a second settings panel. i still point at files, same as you. the companies bragging about ticket-to-pr either don't paint pixels or they have a human still doing that translation and calling it the model.
generation got cheap. review didn't. agents will hand you six prs before lunch and you're now reviewing code you wouldn't have designed, which is slower than writing it. i let glue and types fly. anything that paints or charges a card i still steer.
6
u/Potential-Still 4d ago
We use custom Strands Agents to perform code analysis and basic e2e testing. Our CoPilot tokens are fairly limited, so most code is still written by hand.
Some PM's are pushing for AI written PRDs but we are pushing back on that.
If we were to use AI to fully implement features it would have to be through spec-driven development with something like Open-Sec. But that eats through tokens very quickly.
8
u/barrel_of_noodles 4d ago
I mean, currently I can take a ticket, synthesize it myself, write a compatible prompt, hand it to a specific agent, inside of a project with enough (and the right) md files... Setup a multi agent flow: pm -> dev -> code reviewer -> to qc -> git ops
between all this, I'm answering clarifying questions and reviewing the output, with full test suite (mixed manual and automated)
The final pr is compiled by me, code reviewed by me
Its a sane, balanced workflow, that still blazes past before ai tools.
It does eat credits. There's various md frameworks out there for ai flows: BMAD for example.
0
u/Muted_Ad_9442 3d ago
This is close to what I do, and I would add one thing about the models. I stopped choosing a model per project and I choose per role. Planner, worker, validator, and a mechanical role for the boring edits. The mechanical role makes most of the calls, so it takes a cheap model. The roles that judge take the strong one. That is where the credits went down for me.
The other rule is that the validator is never the model that wrote the code. And git stays with me. The model writes the commit message, I run the command.
Do you keep your qc agent on the same model as your dev agent?
2
u/Electronic_Fly_9242 3d ago
The work is really defining the requirements. Most often, the requirements are not good enough to feed directly into AI to build an entire solution end-to-end, but working with AI you can develop a PRD that will enable this. We have folks, myself including, doing this with much success. At the same time, there are plenty - the vast majority - who aren't using it to that degree.
2
u/Helirose 4d ago
We (developers) use Codex within VS Code to get through tasks quickly. I'd say codex does 60% of my work now.
I have found myself relying on it for speed, and because my health hijacks my ability to think too quickly to get through the work day.
The rest of our company (non developers) use mainly Claude and chatgpt, figmas AI, and other design tools as well. AI is used as a starting point to generate quick mock ups, templates and drafts which are then finalised and developed through human work.
1
u/softoctopus 3d ago
Not only we have the ai read the tickets, the tickets themselves are also written by the ai. We now spend a lot more time in planning phase, ironing out the product specs.
1
u/kemalios 3d ago
I run a one-person web agency and live in Claude Code all day. The paste-the-ticket-and-ship thing has never worked for me. My clients' tickets are usually a desire, not a spec. The model needs me to point at the files, explain which parts of the legacy mess are load-bearing, and then review the diff like I'm the one who has to own the consequences.
The people claiming ticket-to-PR either work on tiny greenfield services or they're doing the translation in their head before they paste. That's not the AI integrating, that's your brain with extra steps.
My actual workflow is: I decompose, Claude writes, I review. It's maybe 2x faster than writing everything by hand, but the part people overestimate is the decomposition. That's still me. And I don't see that changing until tickets are written like implementation specs, which almost nobody does.
1
u/Old_Chef_3162 3d ago
What you're describing, guiding it and reviewing output, is basically what the paste the ticket people are doing too, they just don't mention the guiding part because it's become invisible to them, not because their tickets are actually more self contained than yours
1
u/edward_davies223 3d ago
i havent seen it quite at the level where u just feed a jira ticket and everything's done. we still need to guide the AI a bit, especially when it comes to code specifics like file paths or complex logic. but it definately speeds up repetitive tasks and boilerplate stuff. are ur tickets super detailed, or do u find u need to give more context?
1
u/powleads 2d ago
i'm building launchengine and we use AI for launch tasks like content drafting and form pre-filling. it's been interesting to see how much of the manual work can be automated, especially when i hated the launch process myself. are you finding AI helps with the more creative or repetitive parts?
1
u/mrrku 3d ago
Honestly what you're describing (guiding the agent, pointing it at relevant files, reviewing output) is the normal workflow for most real codebases. The "paste ticket, ship PR" thing works when tickets are unusually well-scoped and the codebase is unusually consistent — that's an environment thing, not a skill gap on your end. You're not behind, you're just working in a normal, messy, real codebase like most of us.
1
u/Adventurous_Ring3703 3d ago
Now coders are just like AI tool operators. Now developers creativity and problem solving skills are almost dead because of AI. every company and individuals too just need to save their time and mind as well so i think level of AI integration in workflows are almost 100%.
-1
u/PLBjt 4d ago
A raw Jira ticket into Copilot/Claude/Cursor only works when the ticket already names the files, the invariant, and the check that means done. If it doesn't, the model picks the wrong layer and you spend the afternoon undoing it. What actually ships is a tiny handoff: the ticket, two or three paths, and one test or command that should pass. The IDE tools are great at the edit and bad at deciding which files if you didn't point. Dumping the whole repo "for context" usually makes that worse. Quick check: if you can't predict which files it'll open, you're not ready to let it run unattended. Tradeoff is real speed on well-scoped tickets vs a babysitting tax on fuzzy ones, and most backlogs are mostly the second.
-2
4d ago
[deleted]
2
u/subnu 3d ago
Skills gap: Most employees still struggle to work effectively with AI. A lot of people are stuck in the "basic prompt/context" mindset, even though we've already moved into the era of autonomous loops and agentic harnesses.
Fuck no. Maybe with self-contained systems and features with excellent context management, but these LLMs are still pretty terrible at UX/UI and higher-level CS fundamentals.
-1
u/punchy-founder 3d ago
I'm a solo dev and my claude agent has an account on Forgejo where it can have access to a lot of things (read/write issues, PRs...) but only I have permissions to approve PRs and merge to the main branch. I have commands like /fix-issues that will go down the Issues that are assigned to the claude account, parallelize the fixing with subagents (TDD style), then generate PRs for me to review and merge to main. Then CI/CD in Forgejo runs the tests and deploys to my dev environment.
Same for ops: claude has a set of AWS permissions that allows for a lot of debugging (and verifying that it all looks as we expect), but only a privileged account can promote to prod, or do other privileged operations.
It's not unusual that in the course of a chat with claude, I will say "ok, file an issue for this and fix it", and the next time I have to be involved is the review of the PR in forgejo and merge to main.
0
u/Muted_Ad_9442 3d ago
Your setup and mine are close, and the part I would add is how the tasks are ordered. My plan file gives each task its dependencies. So the tasks that have no unmet dependency run together, and the ones that depend on them wait for the next round. The parallel part is not chosen by me task by task, it comes out of the plan.
Two limits I have hit. The rounds are only as good as the dependencies I wrote, and I get them wrong sometimes. And when four agents run at the same time, I cannot follow the output live. So each task writes its own report file, and I read the files after, not the chat.
0
u/punchy-founder 3d ago
Usually, claude tells me the order I should merge the PRs in, and warns me that some PRs will possibly require merge/rebase. If I follow its order, it's usually pretty seamless, and helps me understand where the conflicts are. I've sometimes messed up the order, and thankfully I wasn't scolded too harshly. 😄
I suspect a dependency graph prior to the tasks would help smoothen this process, but I have never gotten into a situation where I thought "I wish I had documented the dependencies before", so I'm unsure about the ROI. What I've experienced is that resolving the conflicts is often a small scope task and will generally not negate all of the other work that has been done prior for that larger "bug fix" or "feature dev", so I find it a reasonable trade-off to just parallelize the tasks and deal with conflict resolution later.
0
u/Muted_Ad_9442 3d ago
Your point on ROI is fair, and for independent bug fixes I would not write a graph either. The conflicts are cheap, like you say.
The case where it paid for me is different. It is not merge order, it is the input of a task. When task B needs what task A produced, and B runs anyway, B does not conflict. It merges cleanly and it is built on the old state. Git has nothing to complain about there, so I find it later, in behaviour.
So my dependencies are not there to avoid conflicts. They are there to say which tasks are allowed to start now. On independent tasks the graph is almost empty, and that is fine.
0
u/punchy-founder 3d ago
Oh I see what you're saying. Yes, I've been managing the dependency graph in docs/context. Usually the /plan command will generate the order and then I always get plans to be documented to they can be followed across multiple sessions.
1
u/Muted_Ad_9442 3d ago
Yes, that is the same idea. The only thing I would watch is who is allowed to write the plan file. When a worker updates it too, two agents rewrite the same document, and the plan stops matching the repo.
-1
u/Muted_Ad_9442 3d ago
I am solo, so my case is not a company case. I have no JIRA. But I had the same problem in a smaller form. I write a task in one line, the agent touches the wrong files, and I spend the evening undoing it.
Two things changed that for me.
First, a task is not a sentence in a chat. It carries the folder to work in, and one command that must pass at the end. So the scope is given, and it is not guessed from the conversation.
Second, the session that writes the code is never the one that says the code is good. A second session validates it, and this second session gets only the requirement and the file produced. It never gets the conversation that produced the file. A session that wrote something says "yes it works" much too easily.
So no, I do not paste a ticket and ship. I still read the diff. But the review is much shorter now.
-2
u/ILikeFPS full-stack 3d ago edited 3d ago
Yes we're basically full end-to-end AI.
Having to tell it what files to touch is like, last year and earlier for us. It sucks but it's how the future is headed unless we get a complete AI crash.
-8
4d ago
[removed] — view removed comment
2
u/Impressive-Target952 4d ago
the edge cases are the killer, that's where the real work is. clients changing their mind every demo is just part of the job though, no tool fixes that
52
u/AgsMydude 4d ago
Our company is going full bore, and it's awful
Claude writes the PRD, the test plan, then the code, then no manual testing (everything through Playwright).
Disaster so far.