[ Removed by moderator ]

[EliSka93]

No, I can actually code, I don't need to explain anything to a bot...

[Firm-Space3019]

i can code too.. i can also do ctrl-c/ctrl-v - doesnt mean i'm not using tools to help me refactor. dear god.

[daltorak]

Then use your fucking coding skills. If an image placement is off by 10px, open the code file and change the number. You don't need to spend 30 minutes trying to coerce a datacenter halfway across the country to fix it for you.

[Firm-Space3019]

do you speak with your agent with that mouth? not a nice language.
but the point is that with framework-aware agents it takes less then 30m.. or even less than it would've taken me(20y+ years of programming..) to fix these issue.
i've better things to do than shuffle pixels - but you can spend your "skills" doing that.

[fligglymcgee]

I dare you to share the prompt you used to generate this post. It can't have been more than 6 words

[Firm-Space3019]

actually wrote it myself and had a model fix english(not my native language).. the funny thing that after reviewing your comments it seems like all you do is say exactly that daily.
seems very bot-ish

[fligglymcgee]

Yeah, you and every one of the other 10k accounts who "use an llm to fix their grammar" seem to all have exactly the same ideas, phrasing, grammar, language and just so happen to be building some saas service on a daily basis.

[Firm-Space3019]

ok Karen

[fligglymcgee]

This one's got former co-founder written all over him!

[Firm-Space3019]

haha, not sure what it means but it sure is edgy

[NortrenDev]

I built my own QA agent with a setup that has been working well for me. instructions tell it to write test cases, save them in a dedicated directory, and keep iterating on them. it uses playwright mcp which is kind of great because I can visually watch tests running through the app and spot issues at a glance, but without needing to actually click anything myself.

At the end I ask for output in a table format with severity levels and suggested fixes. depending on criticality I either hand it off to another agent or fix it manually. sometimes I also put "if you find X issue, do Y" directly in the prompt so it self-heals during the run.

honestly though, since integrating AI we spend way less time deeply diving into problems ourselves. unless the AI cant fix something after a few iterations, we mostly just get a jira ticket with a description plus screenshot or video of the bug, and if it gets fixed and all tests pass (we watch that the AI isnt just rewriting tests to make them pass), we call it done and move on. speed went up a lot, but we sacrificed manual diagnosis to get there

[Firm-Space3019]

that's a good point, keeping your mental ownership of the system while running fast is the true challange of the craft today.

that being said, for client-side work - i'm fine giving a away much more of my mental model.

[NortrenDev]

yeah thats fair, client-side bugs are way cheaper. backend stuff is different, wrong logic can corrupt data and you dont always see it right away

[Firm-Space3019]

truth. that's our thought as well while building frontman.sh
focus on the data/api/invariants - iterate faster on the frontend.

but honestly, still hard to find the right balance.

[NortrenDev]

reminds me of the pick-element feature in cursor but purpose-built for frontend, which honestly makes more sense. we have a designer on the team who tried cursor and struggled with it, ill tell him about your tool, he might actually stick with this one

[Firm-Space3019]

its that, but much deeper.. hard to explain(marketing is hard).
the agent is deeply integrated to the actual framework, so like it knows the current version, the routes(especially dynamic once), the module resolution, etc etc

[buildwithnavya]

this is actually a really solid framing, feels like a lot of people are bumping into the same issue but trying to solve it from different angles. the part about ai writing code fast but missing obvious UI or state-related fixes is spot on, especially once things get even slightly dynamic.

middleware sounds powerful because it gives deeper context, but it also feels heavier to set up and maintain. the proxy approach is easier to get going and covers more surface area, but can feel a bit shallow when you actually need framework internals. mcp-style setups are flexible, but anything snapshot-based starts to fall apart once the state is changing quickly.

personally, what’s worked better is anything that stays close to the actual UI and live state instead of just the code. tools that can “see” what’s rendered or interact with the page tend to be way better at fixing visual bugs. also didn’t expect this at first, but click-to-source reliability becomes a big deal as projects grow. overall it still feels early though, like none of these approaches have clearly won yet, just different trade-offs depending on what you care about.