AI-Native Product QA Engineer; Business Flows & Operational Quality

An engineer who understands business velocity and takes ownership of real-world operational quality

AIC stands for AI-native IC (Individual Contributor). Moving beyond simply using AI as a support tool, an AIC integrates AI into every step of designing, executing, and validating work, taking direct end-to-end ownership of their outcomes.

Rather than people management, this role prioritizes the ability to leverage AI to get critical work done quickly while ensuring uncompromising quality for real end-users.

MUST Company is a South Korea-based company building AI-native products. This role is fully remote, full-time
, and open to candidates based in any of the countries listed on this posting.

We ship fast. What has hurt us is what comes after: small gaps in a live product that turn into weeks of operation support. A user's settlement alert never arrives. A user completes a task on Sunday, settlement runs on Tuesday, and nobody can say whether it counts. Each case is small, but together they pull engineering time away from building.

We are hiring a QA engineer who stops these cases before users find them. You understand how the business works and how users actually move through the product, and you test against that, not only against the ticket. When a prototype works, you are the person who makes it ready to operate: the edge cases, the dates and time zones, the notifications, the admin settings, the failure paths and the recovery.

This is not a test-case-counting role, and it is not a business-lead role. You will not own the business direction. You will own whether the product works for real users once it is live, and your impact is measured by how much repeat failure and after-the-fact support disappears.

You will work across our live crypto wallet and marketplace products: weekly settlements and payouts, date-based participation rules, seasonal programs, in-app token swaps, notifications and the admin console.

AI is part of how you work (generating test scenarios, reading logs, reproducing issues, automating regression), but you remain accountable for the judgment and the outcome.

• Learn the business rules end to end (who gets paid what, when, and why) and turn them into testable scenarios before release
• Review every feature and proof of concept before release against real user flows, including dates, time zones, weekends and cut-off times, notification delivery, account and login changes, and admin configuration
• Turn every support question or incident into a root cause and a regression test, so the same case does not come back
• Track repeat operation-support requests, group them by cause, and push the top causes into the backlog with clear acceptance criteria
• Build and maintain automated regression for the flows that move money or trigger user notifications
• Define release readiness (what must pass before a change goes live) and hold the line on it
• Work with engineers, product owners and the operations team so fixes land in the product, not in manual workarounds

• First 30 days: the business rules for settlements, participation and notifications are documented as test scenarios, and the last three months of operation-support requests are mapped to root causes
• First 60 days: every release in your scope passes a defined readiness check, and the top repeat support causes have fixes or regression tests in place
• First 90 days: repeat support requests for the flows you own are measurably down, and fewer production issues are found by users instead of by QA

• Portfolio or case write-ups (links are fine) covering 2-4 cases where you found a defect or gap before users did, or turned a production issue into a lasting fix. For each case: the business context, what you found, how you found it, what changed, and the result.
• A Loom video of no more than 5 minutes: one case where your testing prevented operation support or a production incident, how you use AI in your QA work, and what you personally owned.
• Do not submit confidential information, personal data, credentials or API keys from past employers.

• Business understanding: do you test against how the business and its users actually work, not only against the ticket?
• Prevention: can you show defects or edge cases you caught before release?
• Root cause: do you fix the cause and add the test, or only close the…