Four months on the Ansys Fluent R&D team at Synopsys
A short look back at my May to August 2026 software development internship: shipping a feature in two weeks, extending it into Python client libraries, and moving 13+ repos to one Python baseline.
From May to August 2026 I was a software development intern on the Ansys Fluent R&D team at Synopsys, working remotely. I'm keeping this to what is on my résumé and what I learned. The details of the work itself stay inside the company.
Day one: the welcome kit.
What I did
Three things, in the order they happened.
A new plotting feature, in two weeks. I added a plotting feature to Fluent's visualization tool, from the backend API through to the UI. It went out as part of a major customer release used by all Fluent users. Two weeks from start to merged is fast for anything customer-facing.
Extending it to three Python client libraries. Fluent is also driven from Python, through libraries such as PyFluent-Visualization, PyEnSight and PySimAI. A feature that exists in the UI but not in the scripting interface can fail quietly when someone calls it from a script. I extended the feature into those three libraries and added CI and Cypress tests, so a scripting error shows up as a failing check instead of a silent no-op.
Moving 13+ repositories to a shared Python 3.13 baseline. This was the least glamorous piece and the one I learned the most from. I led the move, fixing failing Azure DevOps CI builds along the way, working with the DevOps, Fluids and Fluent Prime teams.
What I took from it
Failing quietly is the worst way to fail. Most of what I did in the second project was about making a mistake loud: a test that breaks, a check that turns red. That is cheaper than a user finding out later.
Build health is a team problem, not a repo problem. With 13 repositories, one bad pin or one old interpreter assumption can block a pipeline that someone else owns. That kind of work is less about changing code and more about finding who owns what, agreeing on a target, and getting each build green without breaking the next one.
Small scope ships. A feature that goes from backend API to UI in two weeks has to stay narrow. I'd rather ship a small thing end to end than a big thing half done.
Large codebases reward reading before writing. That is a general lesson, and it applies to any codebase this size.
Why it matters to me
I want to work on systems, DevOps and developer tooling. This internship covered a customer-facing feature, the test infrastructure around it, and the cross-repo build work that keeps everything else moving. That mix is what I'm looking for after I graduate in May 2027.