DEV Community: Nina Ricci

Part 2: AI Didn't Make Bad Decisions. It Made Different Engineering Decisions Than I Would. 🤔

Nina Ricci — Tue, 04 Aug 2026 11:23:40 +0000

A Series: Building a SaaS with AI as my teammate

In my previous post, I talked about treating AI less like a code generator and more like a new engineer joining the team.

That experiment has been interesting.

What surprised me wasn't that AI generated bugs.

It was that it continuously made perfectly reasonable engineering decisions... based on assumptions I never told it.

And those assumptions slowly shaped the architecture of my project.

The first surprise: package selection 📦

When I started the implementation, I gave AI a lot of context about the project.

It knew the tech stack.
It knew the goal.
It knew this was a side project.

So I asked it to scaffold the application.

The packages it picked were completely reasonable.

After all, it knew this wasn't intended to become a huge enterprise application.

Only after reviewing the pull request did I realize something.

I had never actually explained the quality I wanted. 😅

In my head, this project sat somewhere between:

a weekend hackathon project
a production-ready service I'd confidently deploy

I wanted something lightweight enough to move fast, but structured enough that I wouldn't regret decisions six months later.

AI had no way of knowing that.

It optimized for exactly what I described: a side project.

And that was when I realized something:

AI doesn't just need to understand what you're building. It needs to understand how you think about building it.

Small technical decisions become big later 🧐

The more PRs I reviewed, the more examples I found.

One migration generated by AI looked like this:

no updated_at column
only an up.sql
no down.sql

Again...

Nothing was technically broken.

If this were a quick prototype, I'd probably merge it without thinking twice.

But then I started asking myself:

"Wait... what happens when I need to rollback this migration?" 🤔

"What happens when I want automatic timestamps later?" 🤔

"Why did AI choose this?" 🤔

The answer was simple.

Because I never told it otherwise.

AI wasn't optimizing for long-term maintainability.

It was optimizing for:

"Make this feature work."

And honestly, that's a completely reasonable assumption when you tell it:

"This is a side project."

The problem?

A "side project" can mean many things.

It can mean:

something I'll delete next month 🗑️
something I'll use personally for years 🚀
something that might eventually become a real product 🌱

AI doesn't know which one you mean unless you tell it.

My workflow changed 🔄

Originally my workflow looked like this:

Prompt AI
↓

Generate code
↓

Merge

Simple.

Fast.

But also risky.

Now it looks much more like working with another engineer:

Generate code
↓

Review PR
↓

Ask AI why it made certain decisions
↓

Ask for alternatives
↓

Research tradeoffs
↓

Decide myself

And this honestly feels much closer to how engineering worked before AI.

Before AI, we would:

read official documentation 📚
search through GitHub issues
browse Stack Overflow discussions
read engineering blogs
compare different approaches

The difference now?

AI gives me a starting point much faster.

I can ask:

"What are the tradeoffs?"

Then:

"Give me an example where this approach fails."

Then:

"What if this grows from one engineer to five?"

And suddenly, a decision that might have taken hours of research becomes a much faster conversation.

AI shouldn't own architectural decisions 🚫🤖

One thing I've become careful about is letting AI "recommend" a solution.

Large language models are very persuasive.

Sometimes they'll even say:

"Personally, I think Option A makes more sense."

And sometimes I catch myself thinking:

"Hmm... maybe you're right." 👀

But confidence isn't the same as correctness.

So instead of asking:

"Which one should I choose?"

I ask:

What are the tradeoffs?
When does each approach fail?
What problems appear later?
What situations would make me regret this decision?

The goal isn't for AI to make the decision for me.

The goal is for AI to help me make a better decision.

This project is really an experiment 🧪

The application I'm building isn't just another side project.

It's become an experiment in understanding how AI behaves when context is incomplete.

Every time AI surprises me, I don't immediately think:

"AI got this wrong."

Instead I ask:

"What assumption did it make because I never gave it enough information?" 🤔

Those moments have actually become the most valuable part of this project.

Because every missing piece of context becomes another instruction I can add.

Every review becomes another lesson.

Every decision becomes another piece of information about how I want my AI teammate to work.

And slowly...

AI starts feeling less like an autocomplete tool.

And more like a teammate who understands how our engineering team works. 🤝

In Part 3, I want to explore another interesting pattern I've noticed: how AI changes when you stop treating prompts as one-off requests and start building reusable engineering context.

Part 1: I Stopped Asking AI to Write Code. I Started Teaching It How My Team Works.

Nina Ricci — Thu, 30 Jul 2026 07:51:47 +0000

A Series: Building a SaaS with AI as my teammate

Over the last few years, I've worked on engineering teams where features rarely started with code.

They started with conversations.

A Product Manager would present a problem or feature idea. Engineers would discuss the technical approach, identify risks, challenge assumptions, estimate the work, and agree on the scope. Once everyone aligned, we'd break the work down into issues, implement the solution, open a Pull Request, review it, merge it, and finally close the issue.

Every team I've worked with had its own way of documenting issues and Pull Requests. Some were more structured than others (and yes, sometimes we'd just write the bare minimum 😅). But one thing stayed consistent: there was always a process behind the code.

Then I started building my own SaaS.

Suddenly I was wearing every hat.

Product Manager
Software Engineer
Tech Lead
QA Engineer
Reviewer

Around the same time, I started experimenting with Cursor.

Like many people, my first instinct was to use it as a coding assistant.

"Build this feature."

And honestly... it worked.

Cursor generated code surprisingly well.

But after a while, something felt off.

The code appeared.

The engineering process disappeared.

There were no planning discussions.

No issue breakdown.

No implementation plan.

No clear commit boundaries.

No Pull Request summary.

No reviewer checklist.

It was skipping everything that I had learned from working on software teams.

That's when I realized something.

I wasn't missing a better AI model.

I was missing the team process.

Instead of asking Cursor to simply build features, I started teaching it how my team used to work.

Rather than saying:

Build Google Authentication.

I asked it to:

propose a GitHub Issue
define the scope
describe what is included and excluded
suggest a feature branch
create an implementation plan
identify logical commit boundaries
pause before making large changes
generate a Pull Request description
include a reviewer checklist
document architectural decisions

The difference was immediate.

Cursor stopped feeling like a code generator.

It started feeling like another engineer on the team.

Not because it suddenly became smarter, but because I finally gave it the same context and expectations I'd give a teammate.

Before vs. After

Before

Idea → Prompt Cursor → AI writes code → Commit → Done

I used to just plainly give instructions to AI to build the idea and review the code. If I instruct it to build a whole feature, it spits out a whole chunk of code where I will have to figure out everything on my own. 😅 If I think about using this in production, then it is out of the question. 🙅‍♀️

Now

Idea → Refine the problem → GitHub Issue → Discuss scope → Feature branch → Implementation plan → Small logical commits → Tests → Pull Request → Reviewer checklist → Review → Merge

It looks surprisingly similar to how many engineering teams already work.

The difference is that I'm now doing it as a solo developer with AI helping me execute the process. This is much easier for me to refine the scope, reviewing the code and making changes.

Examples from my project

Once I had this workflow in place, every feature followed the same lifecycle.

Instead of jumping directly into implementation, Cursor first generated an issue describing the feature, the expected behaviour, and the boundaries of the work.

During implementation, I instructed Cursor to stop at logical milestones and recommend commit boundaries instead of producing one massive commit.

Finally, before merging, Cursor generated a Pull Request summary, documented the architectural decisions, and produced a checklist that I could use during review.

What changed?

Something unexpected happened.

The better my engineering process became...

...the better Cursor became.

Not because the model improved.

Because my instructions improved.

I wasn't asking Cursor to write code anymore.

I was teaching it how I wanted software to be built.

That also changed the quality of the output.

The implementation became easier to review because every change already had context.

The commit history became much cleaner because features were naturally broken into smaller pieces.

The Pull Requests became easier to understand because they explained not only what changed, but why.

What AI isn't replacing

One thing I want to be careful about is the narrative around AI replacing roles.

This workflow isn't replacing Product Managers, QA Engineers, or Software Engineers.

It's helping automate the repetitive parts of the engineering process.

The AI can help draft issues, suggest implementation plans, generate Pull Request descriptions, and create reviewer checklists.

But I still decide:

what problem we're solving
the priorities
the scope
the architecture
the trade-offs
whether the implementation is acceptable

The judgement is still mine.

The AI simply helps me execute the process more consistently.

What's next?

This is still very much an experiment.

I'm continuously refining the workflow as I build my SaaS, and I'm learning something new with almost every feature.

From Frontend to Backend: How I Transitioned Across the Stack in a Real Product Team

Nina Ricci — Wed, 03 Jun 2026 06:14:04 +0000

From Frontend to Backend: How I Transitioned Across the Stack in a Real Product Team

I’ve always been more interested in backend engineering since the beginning of my career.

But for a long time, I didn’t really get the opportunity to work deeply on it.

There were a few reasons for that:

Frontend work was less “popular” in most teams, so I often got assigned there
The backend systems in earlier teams were already stable, so there wasn’t much need for hands-on changes
Team structure mattered. I was usually placed in frontend-focused squads

So even though I was curious about backend systems, I naturally ended up building frontend-heavy experience first.

That changed when I joined a product that was being built from the ground up.

🌱 Starting point: Building from scratch in a new product team

In this new setup, I was the sole frontend engineer.

We also had:

a sole backend engineer
a sole data engineer

It was a very lean team building an MVP from scratch.

At this stage, I still focused mainly on frontend delivery but I was already paying attention to how the backend was being designed, because I wanted to understand the bigger picture, and how backend decisions would shape the frontend.

🚀 The turning point: After MVP, the backend needed more hands

Once we shipped the MVP, the reality became clear:

We needed more support on the backend side.

At the same time, management explored whether someone could transition internally from other teams.

That was the moment I saw an opportunity.

Instead of waiting to be assigned, I proactively reached out to my manager and expressed:

my interest in backend work
my willingness to start small
my intention to gradually transition across the stack

I didn’t jump straight into backend ownership. Instead, I built trust through incremental steps:

taking small backend tasks
pairing with engineers when needed
asking for knowledge-sharing sessions
gradually expanding my scope beyond frontend

That was the beginning of my real transition.

⚡ Becoming intentional about cross-stack ownership

What helped me grow wasn’t a sudden switch, it was being deliberate about the kinds of tasks I picked up.

I actively sought exposure to different areas of the system, including:

API design and implementation
backend workers and async processing
third-party integrations
data-related tasks and debugging
alerts and monitoring setups
production issue investigations
documentation and internal knowledge sharing

Over time, I stopped thinking in terms of “frontend tasks” or “backend tasks”.

Instead, I started thinking:

“What does this feature need end-to-end to actually work in production?”

That shift changed how I approached engineering.

🛠 Expanding scope: From features to systems

As I grew more comfortable, I started owning larger and more complex modules across the stack.

I wasn’t just implementing parts anymore, I was responsible for making sure features worked end-to-end, from API design to frontend behavior to production readiness.

At some point, I also began contributing to backend evolution work, working with event-driven systems and message queues like RabbitMQ, as well as making decisions around database design and how we process and consume raw data into our system.

This phase pushed me to think beyond features and start understanding how systems behave under real production constraints.

✨ What stood out most in my transition

Looking back, I think the biggest change wasn’t technical, it was behavioral.

I stopped waiting for backend opportunities
- I actively created them by expressing interest and taking ownership.
I treated scope expansion as a process, not a switch
- Small tasks first → then gradual ownership → then full modules.
I looked for problems across the system, not just my area
- I started engaging with:
  - production issues
  - monitoring gaps
  - reliability concerns
  - documentation improvements

I also became more intentional about making my work easier for others to build on, whether through clearer documentation, better testing guides, or more predictable APIs.

🧠 Final thoughts

My transition from frontend to backend wasn’t really a “career switch”.

It was more of a gradual expansion of responsibility, driven by curiosity and intentional effort.

If I had to summarize it:

I didn’t become a backend engineer by switching roles.

I became one by continuously asking for more ownership across the stack.

And once you start doing that, the labels stop mattering as much as the problems you’re solving.

3 Communication Signals in Engineering Teams That Improve (or Hurt) Productivity

Nina Ricci — Tue, 02 Jun 2026 09:24:40 +0000

3 Communication Signals in Engineering Teams That Improve (or Hurt) Productivity

In engineering teams, progress isn’t always as clear as it looks.
What seems “on track” can quietly hide delays, misalignment, or unclear expectations.

And the challenge is—you often won’t notice these signals unless you know what to look for.

As an engineer, I’ve seen how easily these situations can be misunderstood, especially from the outside. This post is a way to surface a few common patterns and how to respond to them in a way that improves communication and team alignment, rather than creating tension.

1. Underestimating and Overpromising

You might hear something like:

“Yeah, this should be quick. Probably just a day or two.”

…and then it ends up taking much longer.

This usually isn’t intentional. It often comes from:

Underestimating hidden complexity
Pressure to give a fast answer
Not fully seeing edge cases or integration work upfront

💡Instead of calling it out directly—especially in a team setting where it can create tension or make someone defensive—try asking:

“What could potentially slow this down?”
“Are there any risks or unknowns we should consider?”

This keeps the conversation open and helps the team build a shared understanding of what “done” actually involves, without putting anyone on the spot.

2. New Bugs After Every Release

Every release having bugs is normal. No system is perfect.

But if every release consistently introduces noticeable issues, it might signal:

Rushed or incomplete testing
Gaps in QA or review processes
Pressure to ship quickly over shipping safely

💡Instead of pointing it out in a way that feels like criticism, try opening the conversation:

“How confident are we with this release?”
“What parts of the system feel risky right now?”

Framing it this way helps the team reflect together on process improvements, rather than focusing on individual mistakes.

Over time, this can lead to more stable releases and better engineering practices.

3. “I’m Almost Done”

This one shows up everywhere 😅

You’ll hear:

“I’m almost done.”

But “almost done” can sometimes stretch much longer than expected.

This often happens because:

The remaining work is more complex than expected
The final details weren’t fully accounted for
“Done” isn’t clearly defined yet

💡Instead of calling it out directly—especially in a way that might create pressure or tension in a team setting—try asking:

“What’s left before this is fully complete?”
“Is anything blocking you from finishing this up?”

This helps clarify what’s actually remaining and reduces misunderstandings around progress.

Final Thoughts

The goal isn’t to catch people doing something wrong—it’s to improve how the team communicates so issues surface earlier and everyone can work more smoothly together. These are also worth revisiting in tech team retrospectives so improvements happen on both sides.

I’m curious—if you’ve worked in a team before, which of these have you seen the most? And what’s one thing you think makes communication in teams work really well?

How to Trigger React Error Boundary with React Developer Tools

Nina Ricci — Sun, 17 Jul 2022 11:46:16 +0000

What is a React Error Boundary?

According to react.js documentation, Error boundaries are React components that catch JavaScript errors anywhere in their child component tree, log those errors, and display a fallback UI instead of the component tree that crashed. Error boundaries catch errors during rendering, in lifecycle methods, and in constructors of the whole tree below them. (Read more)

Use case

We want to test how our application handles error states. Using the React Developer Tools, we won't be needing to manually force an error state in our code for each component we want to test. Instead, we can just select a component from the tool and force it to be in an error state.

Prerequisites

React Developer Tools chrome extension
- installation
A working React App with React Error Boundary

Demo

Start your React Application and open it on your Google Chrome web browser. (make sure you already have React Developer Tools chrome extension installed)
Open your Chrome Developer Tools and navigate to Components tab.
```
shift + CTRL + J (Windows/Linux).
option + ⌘ + J (macOS)
```
Select a component within the Error Boundary in the tree.
- Notice the (!) icon. Hovering it should show a help dialog "Force the selected component into an errored state"
Click on the (!) icon
- This will force your app to be in an errored state

Git Conflicts; Fixing it with Git Rebase

Nina Ricci — Mon, 07 Feb 2022 09:43:48 +0000

Getting past the basic git clone, commit, add, pull and push, I have learned a few good to know git commands over the years because of repeatedly common problems I've faced when doing version control. I'm planning to create a series for this topic in hopes that this can also help you.

Here's a very short story of how a Git conflict can happen and how to fix it with Git rebase.

Git Conflicts

Usually, these problems are faced when the team gets bigger and a lot more devs are contributing to the same project on the same file.

2 devs working on the same file.

This is very common and it's okay, so don't worry! What I usually do is to plan ahead with the other dev so we know both of us are working on this specific same file. To minimize merge conflicts and efficiently fix them, we want to always rebase from develop whenever there are any changes so we always have an updated version of the base branch.

DAY 1 🌞

dev 1 creates and works on feature A

git checkout develop
git branch -b feature/feature-a
# work on file A

dev 2 creates and works on feature B

git checkout develop
git branch -b feature/feature-b
# work on file A

in between the day, dev 2 who was working on feature B asks for a code review and merges their branch to develop. dev 1 who is working on feature A git add and commits all their changes for the day.

DAY 2 🌞
since, dev 2's branch (feature B) was merged to develop and we know that both devs had worked on the same file, dev 1 (feature A) will now rebase from develop branch to have an updated copy on their current feature branch and fix the conflicts.

dev 1, feature A rebases from develop and fixes conflicts

# don't forget to git add and commit your changes first
git checkout develop
git pull origin develop
git checkout feature/feature-a
git rebase develop
# by this time, git will write your commits on top of develop 
# and you will be seeing the conflicted files

go to the conflicted file and if needed, consult with dev 2 and make sure you save the file where both changes are written.

# resolve conflicted file/s
git add path/to/file
git rebase --continue

git rebase interactive should be done after you finish fixing the conflicted file and you are good to go. 👍

Notice that Feature A now is on top of both develop and Feature B that was merged the day before.

Thank you for reading all the way here! I hope you've learned something new and that this can help you on your productivity and collaboration with your team 🤝

How honesty can improve team productivity

Nina Ricci — Thu, 07 May 2020 13:46:28 +0000

How can being honest actually improve your team's productivity? Let me share with you a few scenarios where you may find yourself in and what you can do and why you should do it.

When you are stuck with your code for more than the usual time it will take to fix something.

Be honest and tell your team you're stuck but make sure you've done your part in trying to fix it. With this, you're likely to progress faster if someone helps you. In fact, it's possible that someone from your team has already encountered it and the time you'll invest for like 1-2 hours could be lessened to a single question.

When something broke and you know it was you who broke it

Be honest and volunteer to fix it. You'll probably take lesser time to fix it rather than someone who has little idea of the cause.

When you don't know the answer to a question

Be honest and tell the person you don't know but try to find the answer after. It's better to tell upfront that you don't know rather than assume something and cause a misunderstanding.

If no one has been honest yet, be the first one

Other members can feel comfortable being honest themselves if someone within the team continuously do so. Everyone would feel that they can trust each other. The feeling of not being discriminated of not knowing or of making mistakes can improve the team's communication. Anyone could learn a thing or two just by someone saying "I don't know" or "I'm stuck. Can someone help me?". And without you knowing it, honesty has become one of your team culture.

DEV Community: Nina Ricci

Part 2: AI Didn't Make Bad Decisions. It Made *Different* Engineering Decisions Than I Would. 🤔

A Series: Building a SaaS with AI as my teammate

The first surprise: package selection 📦

Small technical decisions become big later 🧐

My workflow changed 🔄

AI shouldn't own architectural decisions 🚫🤖

This project is really an experiment 🧪

Part 1: I Stopped Asking AI to Write Code. I Started Teaching It How My Team Works.

A Series: Building a SaaS with AI as my teammate

Before vs. After

Before

Now

Examples from my project

What changed?

What AI isn't replacing

What's next?

From Frontend to Backend: How I Transitioned Across the Stack in a Real Product Team

From Frontend to Backend: How I Transitioned Across the Stack in a Real Product Team

🌱 Starting point: Building from scratch in a new product team

🚀 The turning point: After MVP, the backend needed more hands

⚡ Becoming intentional about cross-stack ownership

🛠 Expanding scope: From features to systems

✨ What stood out most in my transition

🧠 Final thoughts

3 Communication Signals in Engineering Teams That Improve (or Hurt) Productivity

3 Communication Signals in Engineering Teams That Improve (or Hurt) Productivity

1. Underestimating and Overpromising

2. New Bugs After Every Release

3. “I’m Almost Done”

Final Thoughts

How to Trigger React Error Boundary with React Developer Tools

What is a React Error Boundary?

Use case

Prerequisites

Demo

Git Conflicts; Fixing it with Git Rebase

Git Conflicts

2 devs working on the same file.

dev 1 creates and works on feature A

dev 2 creates and works on feature B

dev 1, feature A rebases from develop and fixes conflicts

How honesty can improve team productivity

When you are stuck with your code for more than the usual time it will take to fix something.

When something broke and you know it was you who broke it

When you don't know the answer to a question

If no one has been honest yet, be the first one

Part 2: AI Didn't Make Bad Decisions. It Made Different Engineering Decisions Than I Would. 🤔