DEV Community: Tien Do

When I Use AI — And When I Don’t

Tien Do — Mon, 12 May 2025 12:44:20 +0000

AI helped me ship faster, but it didn’t always allow me to ship better. Over time, I learned to separate speed from clarity and to use AI with more intention, not more dependence.

I started using ChatGPT in late 2022, right after getting laid off. With no job, I had time — so I talked to it constantly. Some days, I spent 5–6 hours experimenting. Ideas bounced back and forth.

At first, everything felt smooth. No red flags yet.

After landing a new job at another startup, I integrated AI into my coding workflow. It felt like magic. Snippets, tests, and scaffolds appeared instantly. I called it my tireless junior dev.

But a few weeks in, I noticed something off: I was shipping more but thinking less. Worse — I felt detached from the codebase.

I used AI to refactor code, build new features, generate controller logic, mock APIs, and especially write RSpec tests. It saved me hours. I enjoy TDD, so I didn’t want to outsource that part — but I had to admit, the output was decent. Part of that came from my prompting skill — I’d spent months sharpening it during unemployment.

On the surface, things looked efficient. PRs moved quickly. I felt productive. But the longer I used it, the more invisible costs started to show.

🚨 Problem 1: Fixing AI output took time

When I used AI to generate logic-heavy code, I often spent more time fixing than writing. That’s not AI’s fault — it's about knowing when to use it, and where to trust my clarity instead. Even with multiple options, most suggestions weren’t up to my quality bar.

🧠 Problem 2: I outsourced my thinking

This one hit harder: critical thinking got slower. I realized I'd gradually handed over my problem-solving process to an assistant. It gave me the illusion that I don't have to think. I get paid to think. To solve real problems. Not to polish suggestions from a prediction engine.

⚡ Problem 3: I became less patient

AI gave me instant answers and I started expecting instant progress. I’ve never been perfectly patient. But, before AI, I at least respected the time it took to solve hard problems. With AI, I got frustrated faster. The illusion of speed trained my brain to expect shortcuts. And when the dopamine stopped, so did my tolerance for difficulty.

📉 Real-World Consequences

When we use AI without thinking clearly, small problems pile up fast:

Code looks like suggestions, not real decisions
Debugging gets messy — nobody fully understands what the code is doing
New teammates have to guess what’s going on
You start to feel disconnected from the work

AI helps move fast, yes. But if you're not careful, it also helps you get lost faster.

🛠 What I Do Now

After another layoff (at the time of writing), I took a step back, not to quit AI, but to rebuild how I think with it.

I went back to basics: pen, editor, whiteboard. Tools that slow me down just enough to reconnect with the thinking process itself.

I still use AI — just differently now:

Dummy data
JSON scaffolds
Boilerplate test helpers
...

But for core architecture, debugging, or solving hard logic, I slow down and use my brain first. If I bring AI in, it’s as a sparring partner, not the driver.

🧭 Final Thoughts

AI isn’t bad. But full dependence is.

Google helped. Stack Overflow helped. Social media helped. But overused? They made us distracted. AI just scales that effect.

So now, I ask myself:

Does this tool increase clarity?
Or does it let me avoid thinking?
Could I still solve this without help?

Try going AI-free for a week — not as a protest, but as a test.
Watch how your brain responds. Track how often you revise AI output vs. your own. Is speed giving you clarity? Or just comfort?

Tools will evolve. AI will stay. But clarity — that’s on us.

I’ve made these mistakes too. That’s why I’m setting better boundaries. Still improving. Still figuring it out — like everyone else.

3 Real-World Refactoring Principles That Help Me Tame Complexity in Startup Codebases

Tien Do — Sun, 20 Apr 2025 07:41:54 +0000

In my previous post, I talked about software complexity.

One principle I consistently follow is:

👉 “The code I touch should be easier to understand and maintain than before—unless I’m writing it from scratch.”

I always start with the smallest unit in OOP—which, coming from a Ruby background, is the function.

To me, a function is the most fundamental building block of a class. Even if a class is 1,000+ lines long, the codebase is still workable if its functions are clear and well-structured. At the very least, it becomes easier to refactor in the future.

In this post, I want to share three principles I use to write clean, maintainable functions:

1️⃣ `Keep It Short (Lines of Code)`

In Ruby, it’s idiomatic to keep functions short.

When I was a tech lead, I often set a soft limit of 10–12 lines per function. But depending on the team’s experience level, that might be too strict and slow the team down.

A practical compromise I’ve found:

20 lines is a reasonable maximum.

It keeps functions simple, readable, and maintainable—without introducing unnecessary friction for the team.

📌 Example: Before & After

Before: A long, hard-to-scan function mixing multiple behaviors

def process_payment(user, order_id)
  order = Order.find(order_id)
  raise "Order not found" unless order

  payment_gateway = PaymentGateway.new(user.payment_token)
  payment_result = payment_gateway.charge(order.amount_cents)

  if payment_result.success?
    order.update!(status: :paid, paid_at: Time.current)

    AnalyticsLogger.log_payment_success(user.id, order.id)

    NotificationService.send_payment_confirmation_email(user, order)

    if user.referral_code.present?
      reward_service = ReferralRewardService.new(user.referral_code)
      reward_service.process_reward_for(user)
    end

    SendThankYouGiftJob.perform_later(user.id) if order.amount_cents > 100_000
  else
    order.update!(status: :payment_failed)
    ErrorTracker.notify("Payment failed", user_id: user.id, order_id: order.id)
  end
end

After: Refactored with clarity, separation, and single-purpose focus

def process_payment(user, order_id)
  order = Order.find(order_id)
  raise "Order not found" unless order

  if charge_order(user, order)
    handle_successful_payment(user, order)
  else
    handle_failed_payment(user, order)
  end
end

def charge_order(user, order)
  result = PaymentGateway.new(user.payment_token).charge(order.amount_cents)
  return false unless result.success?

  order.update!(status: :paid, paid_at: Time.current)
  true
end

def handle_successful_payment(user, order)
  log_payment_success(user, order)
  notify_user_of_payment(user, order)
  reward_referral_if_applicable(user)
  send_thank_you_gift_if_high_value(user, order)
end

def handle_failed_payment(user, order)
  order.update!(status: :payment_failed)
  ErrorTracker.notify("Payment failed", user_id: user.id, order_id: order.id)
end

def log_payment_success(user, order)
  AnalyticsLogger.log_payment_success(user_id: user.id, order_id: order.id)
end

def notify_user_of_payment(user, order)
  NotificationService.send_payment_confirmation_email(user, order)
end

def reward_referral_if_applicable(user)
  return unless user.referral_code.present?

  reward_service = ReferralRewardService.new(user.referral_code)
  reward_service.process_reward_for(user)
end

def send_thank_you_gift_if_high_value(user, order)
  return unless order.amount_cents > 100_000

  SendThankYouGiftJob.perform_later(user.id)
end

2️⃣ One Reason to Change

A function should have only one reason to change. This aligns with the Single Responsibility Principle.

A quick test:

Ask yourself, “What does this function do?”
If the answer includes “and” (e.g., “It charges the user and sends a confirmation email”), it’s doing too much.

In the original example, the process_payment function had several reasons to change:

Payment logic

Logging behavior

Notification flow

Referral rewards

Async background jobs

Now, each function focuses on just one behavior, making changes easier and less risky.

3️⃣ Consistent Level of Abstraction

This one’s subtle but powerful.

If a function mixes different levels of abstraction, it becomes mentally exhausting to understand.

In the original version, the function:

Accessed the database (low-level)

Called an external payment API (infrastructure)

Applied business rules (mid-level)

Sent notifications (I/O)

Triggered background jobs (infra)

That’s a lot of context-switching in one place.

In the refactored version:

The main function (process_payment) stays at the orchestration level

Each helper function stays at a consistent “altitude”, making the whole flow easier to follow and evolve.

I’d love to hear your thoughts.
What principles do you follow to keep your functions clean and maintainable?
Let’s discuss 👇

First post and complexity in software engineer

Tien Do — Sun, 23 Feb 2025 23:44:45 +0000

A Bit About Me 👋

Welcome to my technical/non-technical sharing on Dev.to! I’ve been making a living as a software engineer (with stints as a product owner and tech lead) since 2016. I gained most of my experience in startups—full of challenges, but every struggle was worth it.

In this space, I'll share my thoughts on software engineering and the tech industry—covering both technical insights and the broader business aspects.

This is my first technical blog—or technically, my second. I wrote one before but deleted it because I didn’t think it was good enough. 😅 I do use AI tools to help refine my writing—rephrasing, proofreading, and improving clarity—since English is not my native language. But the core ideas in every post are mine, based on real-world experience in the tech industry.

Why I’m Writing on Dev.to ✍️

1️⃣ For my future self—so I can look back and see how far I’ve come.

2️⃣ For others on a similar path—sharing what I’ve learned along the way.

3️⃣ For my future colleagues/partners—so they can understand how I think about software engineering.

That said, these are not my final opinions. Ideas evolve—especially in this AI-driven era—so my thoughts will too.

Take everything with a grain of salt. 🧂 If you have different opinions, feel free to challenge them! I don’t know how long or how often I’ll be sharing here, but for now, I have the motivation, so… I’m just going with the flow.

Alright, enough intro—let’s dive in. 🚀

Complexity Enlightenment 🤯

Today, I reread A Philosophy of Software Design by John Ousterhout.

Right in Chapter 1: Introduction (It’s All About Complexity), this paragraph hit me hard:

"This means that the greatest limitation in writing software is our ability to understand the systems we are creating. As a program grows and adds new features, it can become complex. This complexity arises from the hidden connections between its parts. As systems grow, they become more complex. This makes it difficult for programmers to remember everything when making changes. This slows down development and leads to bugs, which slow development even more and add to its cost. Complexity increases inevitably over the life of any program. The larger the program, and the more people that work on it, the more difficult it is to manage complexity."

Reading this paragraph summed up all the struggles my past teams and I faced. It captured the essence of our frustrations.

When reading technical books, some sections we skim, and some we digest slowly. I’m sure I read this paragraph before, but this time, it hit differently. Maybe some realizations only come with experience.

The funny thing is, I’ve also read Sandi Metz’s books (since my background is Ruby on Rails). She frequently talks about complexity. But truly understanding complexity? That takes time and firsthand experience.

How I Experienced Complexity in Startups 🏗️

The most common pattern I’ve seen in previous startups goes like this:

1️⃣ At the start, we ship code fast.

2️⃣ Over time, things start slowing down.

3️⃣ Adding new features takes longer and longer.

4️⃣ We scale fast, but our codebase wasn’t built for change (we wrote it just to “make things work”).

5️⃣ We end up fixing more bugs than building new features.

6️⃣ Business teams start asking: “Why did things slow down? It was fast in the beginning!”

7️⃣ Guess who gets blamed? Software engineers. 🙃

Yes, developers play a role, but the real culprit is complexity and dependencies. I’ve seen this pattern repeat in most startups I’ve worked with. The only exceptions? Startups that failed too early—before complexity had time to emerge.

Of course, there are patterns, best practices, and conventions to help control complexity, and I’ll share my experiences with them in future posts.

But here’s the catch: Tools alone don’t solve complexity. Used blindly, they can make things worse.

👉 One extra class, method, or design decision might add hidden complexity that bites us later.

The One Question I Now Ask Before Committing Code 🤔

Before I commit my code, push it, and call it a day, I ask myself one question:

👉 Am I reducing complexity for the codebase/team, or am I adding more complexity?

This has become my main guiding principle before even thinking about a solution.

Final Thoughts & What’s Next 🎯

Additionally, technical decisions should align with business goals. At the end of the day, what’s the point of a technical solution if it doesn’t solve a business problem?

In startups, every decision directly affects how fast we move, adapt, and survive.

For my next posts, I’ll dive into how I handle complexity in real projects.

I’d love to hear your thoughts—drop a comment below! 👇 🚀