AI Tools, Models, and Agents Explained

Most people use AI without really understanding what’s happening under the hood.

You type something into ChatGPT or Claude, get a response, and move on.

But underneath that simple chat box are three very different layers of intelligence: AI tools, models, and agents.

Let’s break them down clearly.

AI Tools: The Chat Layer

AI tools like ChatGPT and Claude are what users directly interact with.

They are designed with a simple interface: a chat box.

At the core of these tools is a large language model (LLM) — the actual “brain” generating responses.

But there’s an important limitation:

These systems are fundamentally stateless.

This means every message is processed independently. The model does not naturally remember past conversations.

So the interaction looks like this:

You ask → it answers
You ask again → it answers again
You repeat → it responds again

Each response is generated from scratch.

Why Memory Changed Everything

To solve this limitation, AI systems introduced memory layers.

Memory allows the system to:

• Store previous context

• Remember user preferences

• Connect past and present conversations

With memory, conversations feel continuous instead of disconnected.

Without it, every message feels like starting over.

What AI Tools Are Good At

AI tools are powerful, but they are best used for interactive exploration, such as:

• Writing code

• Generating ideas

• Creating documents

• Testing concepts

This workflow has led to a new behavior known as “vibe coding”.

A typical pattern looks like this:

You prompt → you review → you copy → you refine → you repeat

It’s fast, flexible, and creative — but heavily dependent on the user.

Because ultimately:

You are the orchestrator, not the system.

The Limitation of AI Tools

AI tools don’t complete workflows — they assist them.

That means:

• You decide what to ask

• You validate outputs

• You connect the pieces

They are powerful assistants, but not autonomous systems.

Subscription Models: UI vs API

AI systems are delivered in two main ways.

1. UI Subscriptions (For Users)

These are the tools people interact with directly.

Examples include:

• ChatGPT (Free, Plus, Pro)

• Claude (Free, Pro, Max)

These are designed for:

• Writing

• Thinking

• Learning

• General productivity

2. API Subscriptions (For Builders)

APIs are designed for developers building systems.

They are used to create:

• AI agents

• Automation workflows

• Backend systems

Instead of chatting, you program the model.

AI Models: Different Brains for Different Tasks

Not all models are the same. Each is optimized for a specific tradeoff between speed, cost, and intelligence.

OpenAI-style model tiers

• Pro models → strongest reasoning, slow and expensive

• Base models → balanced performance

• Mini models → faster and cost-efficient

• Nano models → ultra-cheap, high-volume tasks

Additional specialized models exist for:

• Image generation

• Audio processing

• Video generation

• Deep research

• Coding

Anthropic Model Family

• Opus → most powerful reasoning

• Sonnet → balanced performance

• Haiku → fast and lightweight

Choosing the right model is not just technical — it directly impacts cost, speed, and quality.

AI Agents: From Tools to Systems

AI agents are where things become fundamentally different.

An AI agent is:

A system that can think, plan, and act autonomously toward a goal.

Instead of responding to single prompts, it operates in multiple steps:

• Understands the goal

• Plans actions

• Uses tools

• Executes tasks

• Adjusts based on results

You give it:

• A goal

• Access to tools

• A reasoning model

And it handles the execution.

What Tools AI Agents Can Use

AI agents become powerful when connected to external systems like:

• Google Sheets → manage structured data

• Gmail → send emails

• Slack → notify teams

This turns AI from a chat assistant into an operational system.

System Prompts vs User Prompts

There are two ways to control AI behavior:

User Prompts (AI Tools)

You give instructions directly:

• “Write this”

• “Generate that”

• “Explain this”

System Prompts (AI Agents)

You define behavior rules:

• How the agent thinks

• How it uses tools

• What constraints it follows

System prompts are powerful — but fragile.

• Too strict → the agent breaks or fails tasks

• Too loose → the agent becomes unpredictable

The balance defines whether an AI agent is useful or unreliable.

Multi-Agent Systems

Once you go beyond a single agent, you enter multi-agent systems.

This is simply:

Multiple AI agents working together as a system.

Each agent may have:

• A specific role

• A specific toolset

• A specific objective

Together, they form a coordinated intelligence layer capable of handling complex workflows.

Final Thought

AI is not one thing.

It is a layered system:

• Tools → interaction layer

• Models → intelligence layer

• Agents → execution layer

Understanding this separation is the key to building real AI systems — not just using chatbots.

After 7 years, I was finally able to connect the dots.

Between being a software engineer, using automation tools, and now working with AI.

At first, they felt like completely different worlds.
Now, they feel like different layers of the same idea.

What Software Engineering Really Is

Software engineering shines when you’re building highly customized applications.

You handle everything:

• The UI

• The APIs

• The database

• The infrastructure

• The internal logic

Every part is tightly coupled and manually built.

You write the code.
You call APIs using HTTP libraries.
You design how everything connects.

It’s deep, detailed, and built for technical control.

What Automation Taught Me

When I started learning automation tools, I noticed something familiar.

At the core, both software engineering and automation are about workflows.

But automation operates at a higher level.

If software engineering is embedded and deeply connected, automation is abstracted, reusable, and decoupled.

Instead of building components from scratch, you connect them.

Each piece exposes an input and an output.
The internal complexity is hidden.

It becomes plug and play.

You don’t need to code.
And more importantly, it’s designed for reuse by non-technical users.

AI in Both Worlds

The difference becomes even clearer with AI.

In software engineering, integrating AI means setting up everything:

• A server

• A framework like FastAPI

• The model through a Python package

In automation tools, AI is already there.

You just use a node.
Connect it.
And it works.

A Shift in Perspective

Learning tools like n8n changed how I see software engineering.

Many of the things I struggled to build manually already exist in automation tools, just packaged differently.

It made me realize that what I’ve been doing in software engineering is often the lower-level version of what automation tools simplify.

Where Automation Falls Short

But automation isn’t a replacement.

It has limits.

It lacks rich UI, fine-grained performance control, and support for highly specific use cases.

Most automation flows are linear: trigger to result.

Software engineering, on the other hand, supports multiple touchpoints:

Different interfaces.
Different workflows.
Different user interactions.

It’s not just backend. It’s a full system.

What I Realized

Software engineering gives you control, flexibility, and granularity.
It’s built for complex and large-scale use cases.

Automation tools give you speed, simplicity, and focus.
They’re perfect for smaller, well-defined problems.

Final Thought

Understanding both changed how I approach problems.

I no longer default to building everything from scratch.
And I don’t assume automation can solve everything.

The real skill is knowing when to use each.

That’s what makes the difference.

A business runs on systems.

A system is just a set of processes.

And every process is made of activities.

Activities Inside a Process

Each activity needs to be executed.

There are only two ways it happens:

• A human does it

• A system does it

That’s it.

Human-Executed Activities

Some activities require people:

• Making decisions

• Handling exceptions

• Communicating with customers

Humans bring:

• Judgment

• Context

• Flexibility

But they also have limits:

• They get tired

• They make mistakes

• They cannot scale infinitely

Software-Executed Activities

Other activities are better handled by software:

• Validating data

• Processing transactions

• Sending notifications

• Running workflows

Software brings:

• Speed

• Consistency

• Scalability

It executes the same way every time.

Why Businesses Move Work to Software

The goal isn’t just automation. It’s leverage.

One employee validates 50 sign-ups per hour. Eight hours a day. That’s 400 validations at $200 in daily labor cost.

Replace that with software. Now you’re processing 10,000 sign-ups per hour. Around the clock. No added cost per validation.

That’s a 25x increase in output. Same or lower spend.

You define the work once. The system runs it indefinitely.

The Split

So every business system becomes a mix:

• Humans handle what requires thinking

• Software handles what requires repetition

The goal is simple:

Move repeatable work to software.

Not to replace humans

but to free them from work that does not require thinking.

Where Software Comes From

Software does not appear on its own.

It is built.

By software engineers.

The Role of the Software Engineer

A software engineer takes a business process

and turns parts of it into software.

They:

• Identify repeatable activities

• Define rules for those activities

• Translate them into code

So instead of a human doing the work

the system does it.

Example

Process:

• User signs up

• Data is checked

• Account is created

• Email is sent

Execution:

• User input → human

• Validation → software

• Account creation → software

• Email → software

One process.

Mixed execution.

The Real Responsibility

Software engineers are not just coders.

They decide:

• What should be automated

• What should remain human

• How the system behaves

They shape how the business runs.

The Direction of Change

Over time, more activities move to software.

Because software is:

• Faster

• Cheaper

• More reliable

Now with AI

even more complex activities can be automated.

Final Thought

A business system is a combination of execution:

• Humans for judgment

• Software for repetition

And software engineers?

They build the part of the system

that can run without humans.

Want to test webhooks locally without paying for hosting or domain name?

This setup lets you run n8n on your machine, connect it to PostgreSQL, and expose it to the internet using Ngrok in just a few steps.

1. Download the Project Files

Download and extract the ZIP file containing the Docker setup.

2. Create an Ngrok Account

A. Sign up at Ngrok
B. Copy your auth token from the dashboard
C. Add your auth token to the docker-compose.yml file:

ngrok:
    image: ngrok/ngrok:latest
    container_name: ngrok
    command: http n8n:5678
    environment:
      - NGROK_AUTHTOKEN=XXXX
    ports:
      - "4040:4040"
    depends_on:
      - n8n
    restart: always

Ngrok provides a free way to expose your local services to the internet.

4. Start the Services

Run the following command:

docker-compose up -d

This starts four services: n8n, n8n-runner, PostgreSQL, and Ngrok.

5. Access Ngrok Dashboard

http://localhost:4040

Go to the configuration section and look for a URL like:

URL: https://abc123.ngrok.io

This is your public URL

6. Configure n8n Webhook URL (Important)

Update the WEBHOOK_URL in your docker-compose.yml:

 n8n:
    image: docker.n8n.io/n8nio/n8n:${N8N_VERSION}
    restart: always
    environment:
      - ...
      - WEBHOOK_URL=https://abc123.ngrok.io
      - N8N_PUBLIC_URL=https://abc123.ngrok.io

Updated: If N8N_PUBLIC_URL is not set, n8n generates the OAuth callback as http://localhost:5678/..., which the provider will reject. This means that signing up for Google Sheets, Gmail, Docs, Drive, or Calendar will fail even if the webhook URL is correct.

To test, access n8n using the ngrok public URL. Previously it did not work, but after setting the N8N_PUBLIC_URL, it now works correctly.

Restart the services to apply changes:

docker-compose up -d

This allows external services such as Telegram or Slack to connect to your local n8n instance.

7. Test webhook

Create a Webhook node in n8n. Your endpoint will look like:

https://abc123.ngrok.io/webhook/your-path

You can test it using:

• Postman

• Browser

• External service (Stripe, Telegram, etc.)

⚠️ Important Notes

Free Ngrok URLs change every time the service restarts

You need to update WEBHOOK_URL each time the URL changes

For a fixed domain, use a paid Ngrok plan

Conclusion

You now have a working local setup for testing real webhooks. From here, you can start building and validating workflows before moving to production.

Ever joined a new dev team and had no idea where to start?

You’re not alone.

The difference between a chaotic team and a high-performing one often comes down to documentation. The right documents don’t just inform—they accelerate onboarding, reduce confusion, and keep everyone aligned.

Getting Started & Daily Work

1. Local Development Setup

Your first win: running the app locally.
A step-by-step guide to clone, install, and run the project.

2. Repository Folder Structure

No more “Where does this go?”
Defines how code is organized for easy navigation.

3. Development Process

From planning to release.
Explains sprints, ceremonies, and workflows.

4. Board Workflow

Your task tracking system explained.
Defines statuses, transitions, and WIP limits.

Collaboration & Workflow

5. Git Branching Strategy

Keeps your repo clean and predictable.
Defines branches, naming, commits, and PR flow.

6. Ticket Guidelines

Clear tickets = fewer misunderstandings.
Standardizes types, fields, and priorities.

7. Slack Channels Guide

Know where to post instantly.
Keeps communication structured.

8. Roles and Responsibilities

Who owns what?
Prevents overlap, delays, and confusion.

9. Capabilities and Assignments

Know the expert for each area.
Speeds up problem-solving and collaboration.

System Understanding

10. System Architecture

The big picture of your system.
Shows how components connect.

11. Architectural Decision

Captures key design choices with context, options, rationale, and consequences.

Helps the team understand why decisions were made, trade-offs considered, and their impact on the system.

12. Data Flow Diagram

Tracks how data moves across the system.

13. Swimlane Diagram

Visualizes workflows across components (UI → API → DB → Queue → Worker).

14. Entity Relationship Diagram (ERD)

Explains database tables, columns, and relationships.

Database & Infrastructure

15. Database Access Guide

How to connect to local, dev, staging, and production environments.

16. Database Backup & Restoration

How to safely back up and restore data.

17. Database Management

Covers fixtures, seed data, and schema handling.

Product & Business Context

18. Business Rules

Defines expected system behavior.
Helps distinguish bugs from intended logic.

19. Feature List

A prioritized list of all features.
Guides decision-making for cross-cutting work.

20. Terminologies

Defines domain-specific jargon (banking, commerce, etc.).
Ensures everyone speaks the same language.

Quality & Consistency

21. Style Guide

Standardizes UI/UX (colors, typography, spacing, components).
Prevents inconsistent design.

Delivery & Planning

22. Blueprint (Roadmap)

Your long-term vision (1–2 years).
Broken down into quarterly goals.

23. Product Requirements Document (PRD)

Defines short-term goals, requirements, stakeholders, and timelines.

24. Release Checklist

Avoid last-minute chaos.
Ensures all release steps are completed.

Support & Stability

25. Troubleshooting Guide

First line of defense for support teams.
Reduces unnecessary dev interruptions.

Final Thought

Great teams don’t just write code—they document how they think, build, and operate.

Because in the long run,

clarity scales better than talent.

Struggling to complete tasks on time?

It’s often not about effort—it’s about how tickets are written. Poor tickets create confusion, delays, and unnecessary work.

Fix this, and you’ll deliver faster and build more trust with your team.

The Root Problem

Every task goes through the same flow:

Ticket → Planning → Designing → Development → Testing → Deployment → User

If the ticket is unclear, the issue carries through every stage—leading to delays and wasted effort.

1. Vague Ticket

A vague ticket lacks essential details, forcing the team to make assumptions.

Fix:

Make sure the ticket clearly answers:

• What problem are we solving?

• Who is it for?

• What does success look like?

Use templates and gather details through discussions, research, and documentation.

2. Oversized Ticket

Large tickets are slow and hard to manage.

Problems:

• Slow development and reviews

• Delayed feedback

• Hard to estimate

Fix:

Break work into small, independent tasks (1–2 days each).

3. Unplanned Ticket

Tickets added mid-sprint disrupt priorities and timelines.

Fix:

• Plan thoroughly before the sprint

• Push back on non-critical work

• Leave buffer for unexpected tasks

4. Untestable Ticket

No clear acceptance criteria means no clear “done.”

Fix:

Write testable criteria:

• Given a condition

• When an action occurs

• Then the expected result happens

5. Undefined UI Ticket

No design leads to misaligned expectations.

Fix:

Attach mockups or reference designs to the ticket.

6. Non-Reproducible Ticket

Missing steps make bugs hard to verify and fix.

Fix:

Include:

• Steps to reproduce

• Expected result

• Actual result

7. Open-Ended Ticket

No deadline leads to hidden delays.

Fix:

Set realistic deadlines and consider all current tasks before committing.

Key Takeaways

• Delays are usually caused by unclear tickets, not lack of effort

• Clear tickets reduce rework and speed up delivery

• Small, well-defined tasks are easier to complete and track

👉 Better tickets = faster execution + fewer problems

It all started when I was juggling two worlds — my work projects on Bitbucket and my personal experiments on GitHub.

My Bitbucket setup was running smoothly. I had my SSH keys configured, commits pushed, pipelines running — life was good.

Then one day, I started a side project on GitHub. I made a few commits, felt proud, and hit:

git push origin main

And then — boom 💥 — “Permission denied.”

That’s when I realized my computer was still trying to use my Bitbucket SSH key to talk to GitHub. Time to fix that.

Step 1: Creating a New SSH Key for GitHub

I didn’t want to mess up my existing Bitbucket setup, so I decided to generate a brand-new SSH key just for GitHub.

In the terminal, I ran:

ssh-keygen -t ed25519 -C “personal@gmail.com” -f ~/.ssh/id_ed25519_personal

This created two files:

• id_ed25519_personal → my private key

• id_ed25519_personal.pub → my public key

Then, I copied the content of the public key using:

cat ~/.ssh/id_ed25519_personal.pub

I went to GitHub → Settings → SSH and GPG keys → New SSH key, pasted it in, and saved.

At this point, GitHub knew who I was.

But my local machine still didn’t know which key to use when connecting to which service.

Step 2: Teaching My Computer Which Key to Use

Inside my ~/.ssh directory, I had all my SSH keys:

/Users/jiyo/.ssh

├── id_ed25519_work

├── id_ed25519_work.pub

├── id_ed25519_personal

├── id_ed25519_personal.pub

└── config

That config file is the magic piece that tells SSH which key belongs to which host.

I opened it and added the following configuration:

# GitHub account

Host github.com

HostName github.com

User git

IdentityFile ~/.ssh/id_ed25519_personal

IdentitiesOnly yes

# Bitbucket account

Host bitbucket.org

HostName bitbucket.org

User git

IdentityFile ~/.ssh/id_ed25519_work

IdentitiesOnly yes

Now, whenever I connected to GitHub, it used my GitHub key.

And when I connected to Bitbucket, it used my Bitbucket key.

Simple, but powerful.

Step 3: Testing the Setup

Now comes the moment of truth. At this point, you’ll fall into one of two scenarios:

A. You already have a local project that you want to push to a remote repository

First, link your local repository to the remote one so Git knows where to push your changes. If you’re using GitHub, run:

git remote add origin git@github.com:user/repo.git

To confirm that the remote link was added correctly, use:

git remote -v

If you notice a typo or incorrect URL, simply remove and re-add the remote:

git remote rm origin

git remote add origin git@github.com:user/repo.git

Next, ensure your local branch name matches the remote branch name. For example, if your remote branch is main but your local branch is master, rename it with:

git branch -M main

Finally, push your local project to the remote repository:

git push origin main

B. You already have a remote repository and want to clone it locally

To clone a repository from GitHub, run:

git clone git@github.com:user/repo.git

Or, if you’re cloning from Bitbucket:

git clone git@bitbucket.org:user/repo.git

Both methods should work perfectly. 🎉

Your machine now knows which SSH key to use for each host.

Step 4: Using Custom Host Aliases

Here’s a neat trick I learned later — you can actually give each host a custom alias.

Host github_personal

    HostName github.com

    User git

    IdentityFile ~/.ssh/id_ed25519_personal

    IdentitiesOnly yes

Then, when cloning:

git clone git@github_personal:user/repo.git

This is super useful when you have multiple GitHub accounts (e.g., work, freelance, personal).

You could have entries like github_work, github_personal, and github_freelance, each tied to its own key.

Common Mistakes

You’ve set up a custom SSH host alias, but forgot to use it in your git clone or git remote add origin command.

For example, using:

git@github.com:user/repo.git

instead of the correct alias:

git@github_personal:user/repo.git

Step 5: Don’t Forget

This little line is more important than it looks:

IdentitiesOnly yes

It tells SSH to use only the key you specified — not to randomly try every key it finds.

Without it, you might get errors like:

Too many authentication failures.

So yes, make sure this line is there for each host.

Step 6: Check Your Git User Info per Repository

Everything was running perfectly now — but there was one last thing to remember.

Even though my SSH keys were properly separated, Git still needed to know who was making each commit.

In my work repo, I checked the configuration:

git config --local --list

If my personal email appeared there, I fixed it:

git config --local user.name “Your Work Name”

git config --local user.email “your_work_email@company.com”

And for my personal repo:

git config --local user.name “Your Personal Name”

git config --local user.email “personal@gmail.com”

This ensures I never commit to my company repository using my personal details (been there, done that 😅).

The Final Setup

By the end of it, my .ssh folder looked like this:

/Users/jiyo/.ssh

├── id_ed25519_work

├── id_ed25519_work.pub

├── id_ed25519_personal

├── id_ed25519_personal.pub

└── config

My SSH configuration was clean, my commits were properly tagged, and switching between GitHub and Bitbucket was effortless.

No more “Permission denied.”

No more wrong email in commits.

Just smooth, clean Git operations across all my accounts.

Lesson Learned

If you ever find yourself juggling multiple Git accounts, remember this:

Give each account its own SSH key.

Use a .ssh/config file to tell SSH which key belongs to which host.

Set your Git name and email per repository.

It’s a small setup that saves you from a ton of future headaches.

Now every time I push, it feels like both my work and personal worlds are in perfect sync.

Back in college, I used to think that a “real” programmer built everything from scratch.

If you didn’t write every line of code yourself, it somehow didn’t count.

That, I believed, was what proved mastery.

But once I joined a professional development team, that belief quickly disappeared.

In the real world, time is money.

The longer it takes to build something, the more it costs — not just in hours, but in missed opportunities.

The goal isn’t to reinvent the wheel. It’s to deliver value efficiently.

Frameworks Don’t Make You Less of a Developer

Using frameworks and libraries doesn’t mean you don’t understand technology — it means you know how to leverage it.

You’re standing on the shoulders of those who’ve already solved the same problems, so you can move faster and focus on what truly matters.

Of course, understanding what’s happening under the hood is still important.

That knowledge helps you debug, optimize, and maintain your applications when things inevitably go wrong.

My First Encounter with Frameworks

In my early days as a developer, I worked with Angular, Ionic, and the Slim Microframework.

Before frameworks like Angular, we used to manipulate the DOM manually with plain JavaScript — a tedious, repetitive process that made codebases messy and hard to maintain.

Then came jQuery, which simplified DOM manipulation but still required us to manage everything by hand.

Modern frameworks like Angular, React, and Vue changed the game completely.

They abstracted away low-level DOM operations and introduced declarative programming — a mindset shift where we define what the UI should look like, not how to build it step by step.

Now, when the state changes, the UI updates automatically.

Without these frameworks, it would be much harder to build highly interactive web applications. Time that should be spent developing important features would instead be consumed by managing DOM manipulation — something that can be eliminated in the first place.

Building Once, Deploying Everywhere

Another example of a framework that sped up our development is Ionic.

It opened my eyes to hybrid app development.

Instead of writing separate codebases for iOS (Swift), Android (Kotlin/Java), and the web (JavaScript), we could build a single application that runs on all platforms.

From a business perspective, that meant faster delivery and lower costs — without sacrificing user experience.

Without Ionic, we would need to build multiple versions of the same application for different platforms.

Of course, there are many other frameworks and libraries you can use aside from the ones mentioned here to speed up solution delivery. Don’t hesitate to take advantage of them.

The Takeaway

Frameworks and libraries aren’t shortcuts — they’re accelerators.

They let developers focus on problem-solving rather than rebuilding solutions that already exist.

Looking back, frameworks didn’t make me less of a developer — they made me a more efficient one.

And that’s what real-world engineering is all about: building smarter, not slower.

The Old Way: Installing Everything Manually

Before Docker, setting up a development environment was a manual, messy process.

Back in college, I used XAMPP to get PHP, Apache, and MySQL running. My workflow? Install everything manually, configure it, and drop my project files into the public_html folder buried somewhere inside the OS.

It worked — but barely. Every new project meant tweaking configs, reinstalling versions, or hunting down missing extensions. I thought that was just how web development worked.

Then I discovered Docker, and everything changed.

The Pain of No Isolation

Installing software directly into your operating system is like cooking different dishes in the same pan without washing it in between — things get messy fast.

For example:

Project A needed PHP 7.4, but Project B required PHP 8.2. Switching versions meant uninstalling one, reinstalling the other, and praying nothing else broke.

MySQL updates sometimes corrupted old databases.

Apache ports conflicted when running multiple projects.

Worse, every developer on the team had a slightly different setup. My code would run fine on my machine — but fail miserably on someone else’s.

That inconsistency killed productivity. Hours were wasted debugging environment problems instead of actual code issues.

We weren’t debugging logic — we were debugging our machines.

Enter Docker: The Game Changer

Docker flipped that entire workflow on its head.

Instead of installing everything manually, Docker lets you describe your setup in a simple text file called a Dockerfile. It’s like a recipe that defines exactly which versions, dependencies, and configurations your app needs.

You then build a Docker image from that file — and that image becomes a portable environment you can share.

Your teammates don’t need to install PHP or MySQL themselves. They just run a single command —

docker compose up

— and everything spins up in seconds.

No version conflicts. No missing extensions. No “it works on my machine” nonsense.

Docker in Simple Terms

A Docker image is your project’s blueprint.

A Docker container is the running instance of that blueprint.

You can think of it like baking cookies: the image is your recipe, and each container is a cookie made from that recipe. Every cookie comes out the same — no surprises.

And since Docker runs on Windows, macOS, and Linux, your app behaves exactly the same everywhere.

The Real Impact on Productivity

Once our team adopted Docker, onboarding new developers went from days to minutes.

Before Docker, a new hire might spend an entire afternoon installing dependencies, fixing path issues, or asking why composer wasn’t recognized.

Now? They just clone the repo and run one command. Everything works instantly.

It also made code reviews and deployments smoother. When everyone runs the same environment, the only bugs left are in the code, not the setup.

The Lesson: Code Alone Isn’t Enough

Learning Docker taught me an important truth — writing code is only half the job.

The real challenge is making sure it runs reliably anywhere.

That’s when I started to understand the importance of environment consistency, automation, and DevOps.

Docker didn’t just simplify setup — it changed how I think about building software altogether.

It Started Like Any Other Team Meeting

It was a regular morning meeting. Everyone was gathered around the table while the organizer shared his screen.

As soon as the discussion started, the pace picked up.

People began throwing around jargon, acronyms, and workflows that felt completely foreign to me.

From their tone, I could tell there was a real issue they were trying to solve — and I genuinely wanted to help.

But as the conversation went on, I realized something: I didn’t fully understand what they were talking about, or how all those pieces fit together.

Still, deep down, I knew I could build a solution — if only I understood what they meant.

I thought about asking questions, but I knew it would derail the meeting and take forever.

So I chose to listen and observe carefully.

The meeting ended, and I realized I needed more context before I could contribute meaningfully.

That moment stayed with me and pushed me to reflect.

The Realization That Changed Everything

Later that day, it dawned on me:

Even if you’re an expert in programming, frameworks, and clean code, your impact will always be limited if you don’t understand the business domain — the real world your software is meant to serve.

Without that understanding, collaboration suffers.

And even the most elegant code can completely miss the mark.

That realization changed the way I approached my work.

From that moment on, I made it my mission to truly understand the business domain.

I Took Time to Understand Their Journey and Pain Points

I didn’t have direct access to the end users, so I couldn’t simply ask them what they needed.

And honestly, I didn’t want to overwhelm the requirements analysts with a flood of questions.

Instead, I decided to do my own research first — to explore, learn, and come back to them only to confirm what I’d found. It felt like a more respectful and productive approach.

I started using online resources and AI tools to learn more about our business domain.

I asked about common pain points in this industry, then went deeper — why do those problems exist? What causes them?

To organize everything I was discovering, I started mapping it out visually using simple diagrams.

Step by step, I laid out the journey — each part beginning with a question, followed by the reasons behind it. Then I’d connect that reason to another question, repeating the process until the entire picture made sense.

By the end, I wasn’t just memorizing facts.

I was beginning to see the world through the users’ eyes — and that changed everything.

I Started Exploring Every Term I Didn’t Understand

Once I had a clearer view of the user journey, I shifted my focus to how the business actually worked.

Any time I came across a term I didn’t understand, I looked it up — not just the definition, but the context around it.

Each explanation opened new insights.

And those insights led to better questions — questions that revealed how things truly operated beneath the surface.

It became a cycle: learn a term, uncover an insight, ask a deeper question, and repeat.

With each round, my understanding of the business grew more complete.

Then I Tried to Connect the Dots

But knowing all the terms wasn’t enough.

True understanding came when I started connecting everything together — the processes, the systems, the people, and the reasons behind each decision.

I built a sort of mental map — a hierarchy of terms and relationships — until the information I’d gathered formed a coherent structure.

That’s when it all clicked.

I could finally see how everything worked together — not just as isolated pieces, but as one living, interconnected system.

The Quiet Lesson

That morning meeting taught me something no course or tutorial ever could:

The best developers don’t just write great code — they understand the business behind it.

Because once you understand why something matters, the how becomes much easier to figure out.

And sometimes, understanding doesn’t start with speaking.

It starts with listening, observing, and connecting the dots.

What if being late to a meeting sparked your next big project?

On October 12, 2025, after our quarterly release, I joined an Amazon Q info session hosted by a colleague.

I was late.

By the time I got in, they were already installing Amazon Q on the CLI and VS Code. I just followed along at first—nothing special.

We built small things:

• a snake game

• a car game

• some unit tests

But one thought kept coming back:

“What if this CLI could automate things… or even plug into CI/CD?”

That question didn’t leave me.

The Idea That Wouldn’t Go Away

The CLI felt natural—like using Git. Fast. Simple. Powerful.

At the end of the session, everyone shared their demos.
Mine didn’t go well—I tried building an end-to-end test but hit authentication issues.

No impressive output.

But I left with something better: curiosity.

That night, I opened one of my repositories and started experimenting.

That’s when Git Analytics was born.

The Mistake That Changed Everything

After hours of prompting, I finally got something working.

Then I broke it.

Worse—I accidentally closed my terminal.

Everything was gone.

No history. No context. No way to reproduce what I just built.

That moment taught me something important:

Treat AI experiments like real software.

So I changed how I worked:

• Create a new branch for every idea

• Test outputs

• Commit working results

• Use the goal as the commit message

Then I discovered Amazon Q’s /save and /load.

Now I had:

• Git for code

• Saved context for AI

That combination changed everything.

Learning to Work With AI

At first, I was very step-by-step:

“Do this.”
“Now do that.”

It worked—but it was slow.

Then I changed one thing:

Instead of telling AI what to do,
I told it what I wanted.

That shift made a huge difference.

Suddenly:

• It generated better outputs

• I refined instead of micromanaged

• It felt like collaboration

AI became the muscle.
I became the direction.

When AI Needs You

As Git Analytics grew, things got messy.

Amazon Q started:

• forgetting features

• breaking old code

• getting confused

That’s when it clicked:

AI doesn’t replace developers—it needs them.

It works best in small chunks.
For bigger systems, it still needs guidance.

My dev experience became essential:

• debugging

• structuring

• steering the direction

Without it, I’d just be following the AI—not leading it.

Why I Built Git Analytics

Simple:

Without metrics, we’re blind.

We can’t improve what we don’t see.

Git already has data—but it’s hard to understand.

So I built something simple:

• A multi-repo dashboard

• Runs with Docker

• No backend setup

• Just open and use

Insight without friction.

What the Data Revealed

Once I started using it, the insights were surprising.

👥 Contributors

Not just code volume—but patterns:

• who contributes consistently

• when activity peaks

• how the team moves

🌙 After-Hours Work

Are we overworking?

This shows:

• night commits

• weekend work

• possible burnout signals

🔍 Peer Reviews

Who reviews the most?
Is the workload balanced?

It made collaboration visible.

⚙️ Features vs Bug Fixes

A timeline of:

• building vs fixing

• innovation vs stability

🧪 Test Coverage

Which changes lack tests?

It’s not about numbers—it’s about accountability.

⏱ Lead Time to Merge

This became my favorite metric.

It shows:

• how fast work moves

• where bottlenecks are

• how smooth the process feels

It’s not just speed—it’s flow.

⚠️ Knowledge Risk

This one is powerful.

If one person owns most of a system:

• it’s efficient

• but risky

If they leave, the team struggles.

This helps teams:

• share ownership

• reduce dependency

• stay resilient

Key Takeaway

AI tools like Amazon Q are not replacements.

They are multipliers.

They don’t remove the need for skill—
they make skill more powerful.

Git Analytics didn’t come from a plan.

It came from:

• curiosity

• mistakes

• experimentation

And one late meeting.

Final Thought

The future isn’t:

Humans vs AI

It’s:

Humans who know how to use AI

Download Git Analytics

If I had to explain why Git is so powerful in the simplest way possible, I’d boil it down to just two things:

• It makes copies of code easily

• It tracks changes

That’s it.

But behind these two simple ideas lies the foundation of modern software development.

Why Making Copies of Code Matters

At first glance, “making copies” sounds trivial. But in software development, it’s everything.

This one distinction changes how we build software.

When you want to add a new feature, the workflow becomes:

• Create a copy

• Modify it

• Test it

• Review it

• Commit the changes back to the original

Simple. Controlled. Safe.

#1 Making Mistakes Becomes Cheap

Mistakes are inevitable. But Git makes them cheap.

If something goes wrong:

• You can discard your modified copy instantly

• You can recreate it from the original with a single command

Even better, you don’t have to throw everything away.

You can go back to a specific checkpoint in your code:

Copy A
 → Checkpoint 1
 → Checkpoint 2
 → Checkpoint 3

These checkpoints are called commits.

They act like save points in a game—you can always go back.

#2 Copies Enable Decoupling

Copies don’t just make things safer—they make things organized.

They allow different parts of development to happen independently without interfering with each other.

A typical workflow might look like this:

• Production Copy – Stable code used by real users

• Develop Copy – Where ongoing development is consolidated

• Release Copy – Prepared for upcoming releases

• Feature Copy – For building new features

• Bugfix Copy – For fixing issues

• Hotfix Copy – For urgent production fixes

Without this separation, it would be chaos:

• Unfinished features would reach users

• Untested code would mix with stable code

• Bugs would be impossible to reproduce

• The codebase would constantly be unstable

Copies create order out of chaos.

What About Tracking Changes?

If making copies is one half of Git, tracking changes is the other.

And it’s just as important.

Tracking changes builds a repository

And a repository which makes making copies possible.

These copies are called branches.

The Lifecycle of a Repository

Every repository follows a simple loop:

• You make changes

• You choose which changes to keep

• You commit those changes to a repository

• Then you repeat

Over and over again.

This cycle is powered by change tracking.

Why Tracking Changes Matters

Without tracking:

• You wouldn’t know what changed

• You couldn’t separate tested vs untested code

• Every version would blur into one

With tracking:

• Every change is recorded

• Every version is recoverable

• Every decision is intentional

Tracking gives structure to your work.

Final Thoughts

Git isn’t just a tool—it’s a system built on two powerful ideas:

• Copying enables safety and flexibility

• Tracking enables clarity and control

Together, they allow developers to move fast without breaking everything.

And without them?

It would be pure chaos.

When I first started building systems, I had a very simple mindset:

“Just make the feature work.”

So I did.

After one sprint, I built a table that displays data from an API. It worked. I felt great.

Then the next sprint came.

“Hey, the columns need to be dynamic.”

Alright—no problem. I refactored it. Still felt good.

Next sprint:

“Oh, by the way, this dataset is also used by another tool.”

Okay… now I had to rethink things. I ended up creating a working copy—users edit that, then merge it back into the original. More work, but still manageable.

Then, near the end of the project, things started slowing down.

Some datasets took forever to load.

At this point, I couldn’t just “fix it.” Most of the logic was already baked into the UI. Changing it meant major rework.

And then came another issue—saving data took too long.

So I added background processing.

At this point, I realized something.

None of these problems were random.

They were all predictable.

And I had been reacting to them… one sprint at a time.

The real problem?

I didn’t understand the data.

And I think it’s okay.

no one knows everything upfront you understand the business domain as you go on the sprint cycle.

If I had known the data was dynamic, I would’ve designed the table that way from the start.

If I had known the data would be shared across tools, I would’ve planned for a safer editing flow—like a working copy.

If I had known the data would grow large, I wouldn’t have pushed all the logic into the UI. I would’ve used server-side pagination early on.

If I had known saving would involve large operations, I would’ve designed it with background processing from day one.

Instead, I learned all of this the hard way:

Through rework.

Through delays.

Through “quick fixes” that weren’t actually quick.

So if you’re building something right now, here’s a simple mindset shift:

Don’t just ask, “How do I build this feature?”

Ask:

• “Is the data dynamic?”

• “Who else uses this data?”

• “How big can this get?”

• “Will users perform bulk updates?”

Because features can be built in many ways…

But your understanding of the data will determine whether your system scales—or breaks later.

If there’s one thing I’d tell my past self, it’s this:

You’re not just building features.

You’re designing around data.

And the earlier you understand it, the less you’ll have to rebuild later.

The kind that seem simple at first, but when you think about them deeply, reveal hidden complexity.

Those questions are where the real value is—because they save you time, reduce rework, and prevent wasted resources.

If for some reason you are planning to cancel your current hosting renewal. Then decided to backup your files and database temporarily.

Don’t worry in this blog I will share how you can access those backup on your local

• You can refer to your previous content while migrating to newer hosting provider

• Minimize costs and deploy only once you’re ready

• Do development and testing locally for faster iteration

• Version your changes locally

1. Download the existing files and database from your hosting provider

Example

• public_html.zip

• database.sql

2. Spin up the container

Create a docker-compose.yml file

services:

  wordpress:
    image: wordpress
    restart: always
    ports:
      - 8080:80
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: XXX
      WORDPRESS_DB_PASSWORD: XXX
      WORDPRESS_DB_NAME: XXX
    volumes:
      - wordpress:/var/www/html

  db:
    image: mysql:8.0
    restart: always
    environment:
      MYSQL_DATABASE: XXX
      MYSQL_USER: XXX
      MYSQL_PASSWORD: XXX
      MYSQL_RANDOM_ROOT_PASSWORD: '1'
    volumes:
      - db:/var/lib/mysql
    ports:
      - 3306:3306

volumes:
  wordpress:
  db:

When entering ENV variables values it is important to use the existing username, password and database name from your hosting provider. You want to simulate the existing wordpress on your local machine

We expose the port 3306 of the database so that we can access the database using Database GUI like MySQL Workbench or so on.

After checking the values run the command

docker-compose up -d

3. Copy WordPress Files to Docker Container

Assuming your files are in ~/hostinger_backup/public_html:

docker cp ~/hostinger_backup/public_html/. wordpress:/var/www/html

Note: wordpress is the name of the wordpress container. Run docker ps to check the container name

Tip: Use the dot . to copy contents, not the folder itself.

Then fix permissions inside the container:

docker exec -it wordpress bash
chown -R www-data:www-data /var/www/html
chmod -R 755 /var/www/html
exit

4. Import Database into Docker MySQL

a. Copy the sql file into the container

docker cp ~/hostinger_backup/backup.sql wp-db:/backup.sql

Note: wp-db is the name of database container. Run docker ps to check the container name

b. Import it

docker exec -it wp-db bash
mysql -u XXX -p

 wordpress < /backup.sql

Enter the MySQL password

c. Update site URLs if domain changed:

USE wordpress;
UPDATE wp_options SET option_value='http://localhost:8080' WHERE option_name='siteurl';
UPDATE wp_options SET option_value='http://localhost:8080' WHERE option_name='home';

Adjust http://localhost:8080 to your new domain if needed.

5. Update wp-config.php

Inside /var/www/html/wp-config.php, make sure the database credentials match your Docker setup:

define('DB_NAME', 'XXX');
define('DB_USER', 'XXX');
define('DB_PASSWORD', 'XXX');
define('DB_HOST', 'db');

Common Mistakes when setting DB_HOST

• localhost or 127.0.0.1 is being used instead of db

localhost refer to the wordpress container itself, by using db (service name) docker can resolve it to proper ip address

6. Test your Local Setup

Finally access the site using localhost:8080

Note: If you want to develop and test locally you can change

 volumes:
      - wordpress:/var/www/html

to

 volumes:
      - /path/to/your-folder/:/var/www/html

The AI Shift: Doing More With Less

The rise of AI feels like a turning point.

Almost overnight, developers are expected to do more with fewer people.

At first, I didn’t think much of it. AI felt like a nice-to-have tool. Something you’d occasionally use when you got stuck. Helpful, sure, but not something that fundamentally changed how we worked.

Then reality hit.

Our organization went through layoffs, while some teammates moved on to other companies. Suddenly, the team that once felt complete UI/UX designers, frontend and backend developers, database engineers, DevOps, QA became much smaller.

What used to be a full team started to feel like a body missing several limbs.

For those of us who stayed, the question wasn’t just how do we cope?

It was:

How do we keep moving forward?

What Actually Helped: Experience and Resourcefulness

Looking back, two things helped me navigate that transition.

Experience was the first.

Early in my career, I worked as a junior developer who was thrown into many different areas frontend, backend, infrastructure, and sometimes even things I wasn’t prepared for.

At the time, it felt messy and chaotic.

But in hindsight, that chaos built something valuable: adaptability.

The second thing was resourcefulness.

The ability to figure things out with whatever tools you have.

Both of these qualities are timeless.

Experience doesn’t expire. It just waits for the right moment to be applied again. And resourcefulness doesn’t disappear it evolves alongside the tools available to you.

How Engineers Have Always Found Answers

If you think about it, software engineers have always relied on external tools to solve problems.

First, there were textbooks.

Then came forums and official documentation.

Later, we relied heavily on Google searches and YouTube tutorials.

Now we have AI tools.

The medium changed, but the skill behind it stayed the same:

Knowing what to ask and how to evaluate the answer.

That’s where experience becomes your edge.

Without a mental model of what a good solution looks like, AI can give you a confident-sounding wrong answer and you might never notice.

Prior knowledge isn’t obsolete in the age of AI.

If anything, it’s what makes AI truly useful.

The Hidden Advantage of AI: Faster Mistakes

One thing I’ve realized is that AI doesn’t just make us faster at building things.

It also makes us faster at making mistakes.

And surprisingly, that’s an advantage.

Because mistakes happen sooner, feedback arrives sooner. We can iterate faster, learn faster, and adjust our approach earlier in the process.

A feature that might have taken days to implement can now be drafted in hours.

That means your teammates can review it sooner, test it sooner, and improve it sooner.

The development loop becomes dramatically shorter.

My New Role: The Orchestrator

The biggest shift I’ve noticed in my own work is this:

I’ve gone from being primarily a doer to becoming more of an orchestrator.

Previously, most of my time was spent executing tasks manually:

• writing requirements

• coding features

• refactoring

• writing tests

• documenting systems

• deploying infrastructure

Now, my focus is shifting toward higher-level thinking:

• analyzing problems

• designing solutions

• defining system architecture

• mapping workflows

• evaluating output quality

Once I’ve created a clear plan or pseudocode, I let AI handle much of the implementation.

Step by step.

What This Looks Like in Practice

Here are some examples of how my workflow has changed.

Meetings

Before a meeting, I ask AI to help generate a meeting flow or agenda.
After the meeting, I feed the transcript into AI to generate summarized notes.

I still review everything but the heavy lifting is done faster.

Issue Management

Instead of manually writing every detail in a ticket, I ask AI to help draft:

• requirements

• acceptance criteria

• potential solutions

• expected value or impact

Then I refine the output.

Implementation

For coding tasks:

1. I define the approach or pseudocode.

2. AI generates the initial implementation.

3. I review and test the output.

4. We iterate until it reaches production quality.

Documentation

AI can generate:

• code comments

• technical documentation

• summaries of complex logic

I still verify everything for accuracy and clarity.

Testing

AI can generate unit tests quickly.

Instead of spending hours writing boilerplate test cases, I review and refine what’s generated.

Infrastructure and Deployment

Need infrastructure defined?

AI can generate infrastructure-as-code files like Terraform templates. I review the configuration before provisioning resources.

Releases

Even release notes can be generated automatically based on commits and changes.

Again, the key step remains the same:

Review.

Why Mastering Every Detail Isn’t the Goal Anymore

Software engineering moves fast.

Spending months mastering a specific language or framework only to switch stacks later can be exhausting.

But the fundamentals rarely change:

• variables

• conditionals

• loops

• functions

• data structures

• core programming patterns

Once you understand these principles, you can reason about almost any programming language.

AI can help fill in the implementation details.

Traditional Engineer vs AI-Assisted Engineer

The traditional mindset was simple:

Master everything. Build everything yourself.

The new mindset is different:

Understand the fundamentals and leverage AI effectively.

AI doesn’t replace judgment.

It amplifies it.

The real skill now lies in deciding:

• what problem to solve

• what solution to design

• what output is good enough

Different Ways to Work With AI

In practice, I’ve found three approaches useful.

Vibe Coding

Great for experimentation and quick prototyping.

You move fast, explore ideas, and get unstuck quickly.

Spec-Driven Development

Better suited for production environments where clear specifications and predictable outcomes matter.

AI Agents

Autonomous assistants that can execute multi-step tasks toward a defined goal.

Each approach has its place.

The new skill is knowing when to use which one.

The Real Shift: Supply and Demand

Traditionally, the most valuable skill in software engineering was the ability to build solutions.

But AI is rapidly lowering the barrier to building.

Today, more people can:

• write code

• switch tech stacks

• generate unit tests

• access best practices

• create documentation

…without spending months learning every detail.

This shifts the value of engineering work.

The emphasis is gradually moving toward:

• designing the right solutions

• ensuring system quality

• delivering meaningful impact

Implementation is becoming easier.

Judgment is becoming more valuable.

Final Thought

AI didn’t remove the need for engineers.

But it changed the shape of the job.

The future developer may write less code manually but will spend far more time thinking about problems, designing solutions, and orchestrating systems.

In a world where building is easier than ever, the real advantage isn’t typing faster.

It’s thinking better.