Learning to Make Quality Visible

Why This Direction Made Sense

AI became interesting to me because manufacturing quality knowledge is scattered.

A real investigation may depend on logs, fail codes, process flow, old issue reports, hardware confirmation, equipment behavior, and people’s experience. That knowledge is valuable, but it is not always easy to reach at the moment someone needs it.

The Backend Shift

AI-assisted workflows also changed how I think about backend systems.

They are not always simple request-response pages. They may involve retrieval, long-running tasks, streaming feedback, background processing, concurrent users, and human review.

That is why I started moving beyond Flask-style internal tools and learning FastAPI, async APIs, PostgreSQL, and clearer system boundaries.

For me, AI is not a replacement for manufacturing judgment. It is a way to make quality knowledge easier to retrieve, compare, and act on.

Beyond the Page

A page working locally is not the same as a system people can trust.

When a tool became part of an engineering workflow, the hard parts moved beyond the UI: who could change what, how data moved through the API, how status changed over time, how schema changes affected existing records, and how to understand failures without guessing.

What I Started to Care About

I began paying more attention to things that are easy to ignore in a demo:

• API contracts
• permission boundaries
• database migrations
• automated tests
• logs and error context
• deployment differences
• recovery paths when something goes wrong

That was the difference between building features and building an internal system.

The Moment It Changed

A personal script can be rough.

A shared tool cannot.

Once other engineers started relying on my output, small things became important: what the input meant, why an error happened, whether a result could be reproduced, and whether a change could be traced later.

The Engineering Part

This pushed me into software engineering habits I had not needed as much before.

Git was no longer just a way to save code. It became change history.

MySQL was no longer just a place to store data. It became a way to model products, process steps, failure records, and workflow states.

Error messages were no longer optional. They were part of how another person understood the tool.

That was the first time my scripts started becoming engineering tools.

The Reason

I did not start Python automation because I wanted to become a software engineer.

I started because the same work kept coming back: raw data cleanup, test-log parsing, measurement extraction, yield summaries, weekly reports, and trend charts.

I used Python to turn manufacturing test logs into structured tables and visualizations, extracting fields such as product identifiers, electrical measurements, test items, results, and process context.

The Shift

At first, scripts were just a way to save time.

Then I realized they were also a way to make repeated analysis more consistent. If the same manufacturing logic had to be applied again and again, it should not live only in manual Excel operations or memory.

This was where software became part of my quality workflow.

A Different Level of Ownership

By early 2023, product quality work no longer felt like only reading abnormal data.

Issues such as component damage and FET burnout forced me to connect more layers at the same time: electrical behavior, PCB-level symptoms, process history, hardware confirmation, and yield recovery.

Moving the Problem

The goal was not just to identify a defect.

The real work was moving the problem to the place where it could be fixed: the process condition, the equipment behavior, the handling method, or the control point that created the risk.

That was when product quality started to feel like work I could own with confidence.

The Trap

A fail code feels like an answer when you first see it.

It is not.

A code can point to a direction, but it cannot tell you whether the issue is a false fail, a product defect, a process problem, or an equipment abnormality.

The Evidence Chain

I learned to compare the code with everything around it: logs, retest behavior, position or equipment concentration, earlier process history, equipment condition, and hardware confirmation.

Sometimes the product was fine.

Sometimes the failure was real.

Sometimes the root cause was far upstream from where the fail code appeared.

That changed how I looked at manufacturing data. The signal mattered, but the evidence chain mattered more.

A New Vocabulary

Production had its own language.

Yield, process step, test result, product identifier, schematic, product history, internal system. At first, I was not trying to build anything impressive. I was trying to understand what the data was saying.

Excel was the first translator. I used raw production data and pivot tables to summarize yield, classify results, and draw simple yield trends.

What Started to Connect

The numbers only made sense when I connected them with the process.

For SSD and eStorage products, I learned how units moved through assembly, array-level testing, singulation, and later validation stages. I also started using schematic review to support basic product and circuit-level analysis.

That was the beginning of reading manufacturing as a system, not as isolated tables.

The First Pattern

Most problems did not arrive as clean technical descriptions.

They came as screenshots, vague symptoms, urgent messages, or repeated complaints. My work was to slow the situation down: reproduce the issue, record the context, track the case, and make the next step clear.

What Stayed

I did not know it at the time, but this became a habit I kept using later.

A symptom is not the root cause.

A case needs context.

Repeated issues should become a better workflow, not just more manual effort.