DEV Community: Elizabeth Omito

My Take on Coding With AI & How to Survive the AI Revolution

Elizabeth Omito — Mon, 25 May 2026 13:30:04 +0000

The First Time AI Wrote Better Code Than Me

I didn’t realize coding had changed forever until an AI solved a bug I had been fighting for hours.

I remember staring at my screen after trying everything I could think of, Stack Overflow tabs everywhere, documentation open in another window, multiple failed attempts sitting in my editor like evidence of defeat.

Out of frustration, I pasted the problem into an AI assistant, a few seconds later, it gave me a solution, I ran it and it worked.

My first reaction was excitement, my second reaction was something closer to fear because it wasn't just that the AI fixed the bug. It was how fast it did it.

What took me hours took it seconds and somewhere in that moment, a question quietly appeared in my head:

"If AI can do this already, where exactly does that leave me?"

I think many developers have had some version of that moment. A strange mixture of curiosity, excitement, impostor syndrome, and uncertainty and that feeling hasn't gone away completely.

The Day Programming Changed Forever
Technology always evolves, but this felt different.

Not long ago, AI in development mostly meant autocomplete, Small suggestions, Finishing a variable name, Predicting the next line of code. Helpful, but not revolutionary.

Then things accelerated.

Suddenly AI wasn't just suggesting code anymore, It was generating:

UI components
APIs
Tests
Documentation
Database schemas
Entire project structures

It started feeling less like a tool and more like a junior developer that never sleeps, a junior developer that somehow knows React, Go, Python, SQL, Docker, and twenty other technologies at the same time.

That's impressive and slightly uncomfortable because industry shifts usually happen gradually, this one felt like someone pressed fast-forward.

The Fear Nobody Wants to Admit

Let's talk about the question everyone keeps asking:

Will AI replace programmers?

People debate this constantly online, some say software engineering is finished, others say AI is overhyped, meanwhile, I think many developers are having quieter thoughts they don't always say out loud.

Things like:
"Am I learning the right skills?"
"Will junior developers even have opportunities?"
"What if I'm becoming irrelevant?"

I see it especially among beginners. Many already feel overwhelmed trying to learn programming now they're learning while watching AI generate solutions instantly and experienced developers aren't immune either, years of expertise suddenly feel challenged by tools evolving every month.

The fear is real pretending otherwise doesn't help anyone.

My Experience Coding With AI

I've used AI quite a lot while coding and honestly? some parts have been incredibly useful.

I use it for:

Debugging issues
Learning unfamiliar technologies
Generating repetitive boilerplate
Refactoring messy code
Brainstorming ideas
Explaining concepts quickly

Sometimes it feels like having another developer sitting next to me, especially when I'm stuck but I've also seen the downsides.

AI can confidently generate:

Incorrect solutions
Bad architectural decisions
Fake functions
Nonexistent libraries
Inefficient code

And that's dangerous because it rarely says:

"I'm not sure."

It often sounds extremely confident even when it's wrong, I've realized something important:

AI can make you productive without making you skilled, those are not the same thing, and that distinction matters a lot.

The Dangerous Trap: Becoming an "AI Copy-Paste Developer"

This is probably the biggest risk I see, not AI replacing developers but developers replacing their own thinking.

It's easy to fall into this cycle:

Ask AI for code
Copy it
Paste it
Move on

Repeat that enough times and something starts happening.
You stop thinking deeply, you stop analyzing problems, you stop understanding why things work.

It's similar to using GPS for everything. At first it helps then one day you realize you can't navigate your own city anymore.

AI should amplify thinking, not replace it.

What AI Is Actually Good At

AI genuinely excels at certain things.

Things like:

Repetitive tasks
Boilerplate generation
Documentation
Rapid prototyping
Explaining concepts
Debugging assistance
Code reviews
Test generation

The biggest value isn't intelligence, it's friction reduction. AI removes a lot of tedious work that slows developers down, that's incredibly valuable because most programming isn't writing genius algorithms, alot of it is repetitive work.

What AI Still Struggles With

Despite all the progress, there are still areas where humans matter deeply.

AI still struggles with:

Product thinking
Understanding users
Creativity
System tradeoffs
Communication
Leadership
Context
Judgment

AI can generate code, It still struggles to generate vision and vision matters more than people sometimes realize.

The Developers Who Will Survive the AI Revolution

I don't think future-proof developers are necessarily the ones with the most syntax memorized, I think they'll be people who:

Stay curious
Learn continuously
Understand fundamentals
Communicate clearly
Adapt quickly
Solve problems
Understand systems deeply
Build real things

Syntax changes, frameworks change,tools change, thinking doesn't become obsolete.

The New Skill Nobody Talks About: Asking Better Questions

People talk a lot about prompt engineering, sometimes too much but there is an important idea underneath the buzzwords, Good AI output often depends on good input, instead of saying:

"Build me an authentication system."

You might say:

"Build a JWT authentication system using Node.js and Express with refresh tokens, explain security considerations, and describe why each decision was made."

The difference is context.
Clear thinking produces clearer questions, and clearer questions often produce better answers.

Treat AI like collaboration, not magic.

How Beginners Should Learn Coding in the AI Era
If you're learning programming right now, my advice would be:

Learn fundamentals first
Build projects manually
Use AI as a teacher
Read generated code carefully
Break things intentionally
Learn debugging deeply

Because eventually you'll need to answer:

"Is this code actually correct?"

And you can't fact-check AI if you don't understand code yourself.

The Real Threat Isn't AI

I don't think AI is the biggest danger I think stagnation is. Every major technological shift creates fear before it creates opportunity.

The internet did it, cloud computing did it, Open-source did it, mobile development did it and now AI is doing it too.

The developers most at risk aren't necessarily the ones using AI, they're the ones refusing to adapt at all, fear can sometimes become a bigger obstacle than technology itself.

My Personal Philosophy Moving Forward

I'm not interested in competing against AI, that sounds exhausting, Instead, I want to learn how to work with it intentionally.

I want to:

Stay curious
Continue learning deeply
Build real things
Understand systems better
Keep improving craftsmanship

AI will continue changing, that part feels inevitable but learning, thinking, and creating still belong to us.

Conclusion: Don't Compete With AI Alone

The future probably won't belong to developers who memorize every function and every framework.

It will belong to developers who:

Understand fundamentals
Think critically
Communicate well
Learn continuously
Use AI wisely

AI won't replace developers who know how to think, but developers who refuse to adapt may replace themselves.

“It Works on My Machine”… Until It Doesn’t.

Elizabeth Omito — Mon, 11 May 2026 10:22:35 +0000

You spend hours building a feature, everything runs perfectly on your laptop, and you proudly push your code. Then a teammate pulls it… and suddenly nothing works.

Different errors. Missing dependencies. Version conflicts.

And the worst part?

“It works on my machine.”

That phrase has quietly ruined countless development hours.

As developers, we’ve all experienced that frustrating moment where an application behaves perfectly in one environment and completely breaks in another. Sometimes it’s a missing package. Sometimes it’s a different operating system. Other times, it’s a version mismatch hiding somewhere deep in the setup.

Whatever the reason, the result is always the same: wasted time, confusion, and unnecessary debugging.

Enter Docker: The Fix You Didn’t Know You Needed

This is exactly the kind of problem Docker was built to solve.

Instead of relying on each developer’s environment — which is always slightly different — Docker lets you package your application in a way that runs the same everywhere.

Whether you run it on:

your laptop,
your teammate’s machine,
a testing server,
or the cloud,

the application behaves consistently.

In this article, you’ll understand:

What Docker actually is
Why it matters
The basic concepts you need to get started

No heavy jargon. Just clarity.

So… What Really Is Docker?

In simple terms, Docker is a tool that lets you package your application and everything it needs into a single, portable unit.

That unit is called a container.

But what exactly is a container?

A container is an isolated environment that carries:

your application code,
required libraries,
dependencies,
runtime,
and system tools needed for the app to run.

Instead of depending on whatever is already installed on someone’s computer, the container brings its own environment with it.

That means your application no longer depends on:

the developer’s operating system,
installed software,
or machine configuration.

Everything the app needs already exists inside the container.

Think of It Like a Shipping Container

Docker’s idea becomes much easier to understand when you compare it to shipping containers used in transport.

A shipping container can carry electronics, furniture, food, or clothes. But regardless of what’s inside, the container itself is standardized.

Because of that:

ships can transport it,
trucks can carry it,
and ports can move it anywhere in the world without worrying about the contents.

Docker containers work the same way.

Inside the container is:

your application,
its dependencies,
and its environment.

Outside the container, it doesn’t matter where it runs.

Your app behaves the same whether it’s running:

on your laptop,
your teammate’s computer,
or a production server.

That consistency is Docker’s biggest strength.

Why Docker Actually Matters

Before diving deeper into commands and files, let’s answer the real question:

Why should you care?

Because Docker solves real problems developers deal with every single day.

Consistency

One of Docker’s biggest advantages is consistency.

Without Docker, applications often behave differently depending on the machine running them. A project may work perfectly on one computer and fail completely on another because of:

different operating systems,
missing dependencies,
or software version differences.

Docker eliminates that uncertainty.

Since the entire environment is packaged together, the application behaves the same everywhere. No surprises. No hidden setup issues.

Easy Setup

Setting up a development environment can sometimes take longer than building the actual feature.

You’ve probably seen instructions like:

Install Node.js
Install Python
Install PostgreSQL
Use version X, not version Y
Configure environment variables

For beginners especially, this can become overwhelming very quickly.

Docker simplifies this process.

Instead of manually installing everything, developers can simply run a container that already has the environment prepared and ready to go.

This makes onboarding faster and reduces setup frustration for teams.

Safe Testing

Developers constantly experiment with tools, libraries, and updates.

The problem is that installing things directly on your machine can sometimes break your existing setup.

Docker provides isolated environments where you can safely test applications without affecting your computer or other projects.

If something breaks, you simply remove the container and start again.

Clean. Simple. Safe.

Better Team Collaboration

Team projects become much smoother when everyone works in the same environment.

Without Docker:

one developer may use Node 16,
another uses Node 18,
and someone else may be missing a package entirely.

These small differences create unnecessary bugs and confusion.

With Docker, the environment is standardized for everyone.

The entire team works with the exact same setup, which reduces debugging time and improves collaboration.

This is why Docker has become a standard tool in modern software development.

Let's break down things

Before using Docker, there are a few important terms you’ll keep seeing.

Here’s the simplest way to understand them.

Image → The Blueprint

An image is like a recipe or blueprint for your application.

It contains:

your code,
dependencies,
configurations,
and instructions needed to run the app.

Images themselves do not run. They are templates used to create containers.

Think of it like a recipe card in a cookbook.

Container → The Running Application

A container is a running instance created from an image.

If the image is the recipe, then the container is the actual cooked meal.

Containers are lightweight, isolated, and portable, meaning they can run consistently across different environments.

This is where your application actually runs.

Dockerfile → The Instructions

A Dockerfile is a text file containing step-by-step instructions for building an image.

Inside it, you define things like:

the programming language version,
dependencies,
files to copy,
and commands to execute.

It tells Docker exactly how to prepare your application environment.

Registry → Storage for Images

A registry is a place where Docker images are stored and shared.

The most popular registry is Docker Hub.

You can think of it like GitHub, but for Docker images instead of source code.

Teams use registries to share and distribute application environments easily.

Here is an example

Let’s say you’re building a Node.js application.

You’re using Node.js version 18 on your machine, and everything works perfectly.

But your teammate is using Node.js version 16.

Suddenly:

your code works,
theirs crashes,
and nobody understands why.

Without Docker, solving this might involve:

uninstalling software,
changing versions,
or manually fixing dependencies.

With Docker, you simply define the exact environment your application needs — including Node.js version 18 — inside a container.

Now everyone runs the same setup regardless of what’s installed on their computer.

Problem solved.

This is usually the moment Docker finally “clicks” for most developers.

Getting Started (Keep It Simple)

You don’t need to master Docker overnight.

Just focus on the basics first.

Step 1: Install Docker

Download and install Docker on your machine.

Step 2: Create a Dockerfile

Define your application environment using a simple Dockerfile.

Step 3: Build Your Image

docker build -t my-app .

This command creates a Docker image for your application.

Step 4: Run the Container

docker run my-app

This starts your application inside a container.

And just like that, you’ve containerized your app.

Finally

Docker isn’t just another development tool.

It’s a different way of thinking about applications and environments.

Instead of spending hours fixing setup issues and environment conflicts, Docker helps developers build software with consistency, portability, and simplicity.

It removes the chaos of:

“missing dependencies,”
“wrong versions,”
and “works on my machine” problems.

And replaces them with predictable environments that behave the same everywhere.

So the next time you hear:

“It works on my machine.”

You’ll know there’s a better answer:

“Let’s use Docker.”

Start small. Stay curious. And start building with confidence.

From Click to Connection: The Hidden Journey of Internet Data

Elizabeth Omito — Mon, 20 Apr 2026 23:07:30 +0000

Ever wondered what really happens after you click something?

You tap “send,” open a website, or click a link and something happens instantly.

Behind that instant response is a structured system moving data across networks, devices, and continents in milliseconds.
Ever wondered what really happens after you click something?

You tap “send,” open a website, or click a link and something happens instantly.

Behind that instant response is a structured system moving data across networks, devices, and continents in milliseconds.

So what’s actually making all of this possible?

The System Behind the Internet

To make communication reliable across billions of devices, the internet relies on two structured models: the OSI model and the TCP/IP model.

At a high level, these models define how data moves from one device to another. They standardize communication so different systems can understand each other.

They are not tools or software, but frameworks that guide how data is handled across networks.

Think of It Like Sending a Package

Sending data across the internet is similar to sending a package.

You write the message, package it, label it with an address, and send it through delivery systems until it reaches the receiver, who then opens and reads it.

Each step has a specific role.

In the same way, the internet breaks communication into layers, where each layer is responsible for a specific part of the process.

OSI vs TCP/IP

The OSI model consists of 7 layers, while the TCP/IP model has 4 layers.

Both models follow the same idea: breaking communication into layers so the process becomes easier to understand, build, and debug.

The OSI model is more detailed and conceptual, while TCP/IP is practical and used in real-world networking.

Why This Matters

Understanding these models helps you debug issues more effectively, build better backend systems, and understand how requests and responses actually flow.

It also improves how you communicate with other developers, because you can identify exactly where a problem is occurring instead of guessing.

The Layers

OSI Model

The application layer handles user interaction through browsers and applications.
The presentation layer formats and encrypts data.
The session layer manages connections between devices.
The transport layer ensures reliable delivery of data.
The network layer handles routing across networks.
The data link layer manages communication within a local network.
The physical layer deals with hardware and signal transmission.

TCP/IP Model

The application layer handles high-level protocols such as HTTP and DNS.
The transport layer manages data delivery using TCP or UDP.
The internet layer handles addressing and routing using IP.
The network access layer is responsible for physical data transmission.

What Happens When You Visit a Website?

When you type a URL and press Enter, the process begins at the application layer, where the browser creates an HTTP request.

The transport layer then breaks the data into smaller pieces and ensures it can be delivered reliably.

The internet layer assigns addresses and routes the data across networks.

Finally, the network access layer transmits the data through physical means such as Wi-Fi or cables.

On the server side, the process happens in reverse: the data is received, reassembled, processed, and a response is sent back—all within milliseconds.

Getting Started

You do not need to memorize every layer to get started.

Focus on understanding how HTTP works, how TCP ensures reliable delivery, and how to observe requests using the Network tab in your browser’s developer tools.

This is enough to build a strong foundation.

Final Thought

Every click you make triggers a structured flow of communication across multiple layers.

The internet is not random—it is carefully designed.

And once you understand these layers, you don’t just use the internet—you understand it.
So what’s actually making all of this possible?

The System Behind the Internet

To make communication reliable across billions of devices, the internet relies on two structured models: the OSI model and the TCP/IP model.

At a high level, these models define how data moves from one device to another. They standardize communication so different systems can understand each other.

They are not tools or software, but frameworks that guide how data is handled across networks.

Think of It Like Sending a Package

Sending data across the internet is similar to sending a package.

You write the message, package it, label it with an address, and send it through delivery systems until it reaches the receiver, who then opens and reads it.

Each step has a specific role.

In the same way, the internet breaks communication into layers, where each layer is responsible for a specific part of the process.

OSI vs TCP/IP

The OSI model consists of 7 layers, while the TCP/IP model has 4 layers.

Both models follow the same idea: breaking communication into layers so the process becomes easier to understand, build, and debug.

The OSI model is more detailed and conceptual, while TCP/IP is practical and used in real-world networking.

Why This Matters

Understanding these models helps you debug issues more effectively, build better backend systems, and understand how requests and responses actually flow.

It also improves how you communicate with other developers, because you can identify exactly where a problem is occurring instead of guessing.

The Layers

OSI Model

The application layer handles user interaction through browsers and applications.
The presentation layer formats and encrypts data.
The session layer manages connections between devices.
The transport layer ensures reliable delivery of data.
The network layer handles routing across networks.
The data link layer manages communication within a local network.
The physical layer deals with hardware and signal transmission.

TCP/IP Model

The application layer handles high-level protocols such as HTTP and DNS.
The transport layer manages data delivery using TCP or UDP.
The internet layer handles addressing and routing using IP.
The network access layer is responsible for physical data transmission.

What Happens When You Visit a Website?

When you type a URL and press Enter, the process begins at the application layer, where the browser creates an HTTP request.

The transport layer then breaks the data into smaller pieces and ensures it can be delivered reliably.

The internet layer assigns addresses and routes the data across networks.

Finally, the network access layer transmits the data through physical means such as Wi-Fi or cables.

On the server side, the process happens in reverse: the data is received, reassembled, processed, and a response is sent back—all within milliseconds.

Getting Started

You do not need to memorize every layer to get started.

Focus on understanding how HTTP works, how TCP ensures reliable delivery, and how to observe requests using the Network tab in your browser’s developer tools.

This is enough to build a strong foundation.

Finally It's a wrap

Every click you make triggers a structured flow of communication across multiple layers.

The internet is not random—it is carefully designed.

And once you understand these layers, you don’t just use the internet you understand it. Check out more here

What Actually Happens When You Press Enter on a URL?

Elizabeth Omito — Sun, 15 Mar 2026 12:53:58 +0000

You open your browser, type a URL, and press Enter within a few milliseconds, a website appears on your screen.

But behind that simple action is a complex chain of events happening across the globe: servers communicating, routers forwarding packets, DNS translating names into numbers, and encrypted connections securing your data.

Every time you visit a website, your request might travel through dozens of networks, multiple countries, and thousands of miles of fiber-optic cables before the response returns to your device.

So what really happens when you load a website?

1. The Internet Is a Network of Networks

At its core, the internet is simply a massive global network of interconnected computers.
These networks include:

Home networks
Corporate networks
Data centers
Internet Service Providers (ISPs)
Global backbone infrastructure

Each device connected to the internet is identified by something called an IP address.
Example:
142.250.190.78

This number uniquely identifies a device on the internet, similar to how a home address identifies a house.

2. Domain Names vs IP Addresses

Humans aren’t good at remembering numbers. Instead of typing an IP address, we use domain names like:
google.com
github.com
dev.to

So how does your computer know the IP address of a domain?
This is where DNS (Domain Name System) comes in it works like the phonebook of the internet.

Example process:
User enters: dev.to
↓
Browser asks DNS server
↓
DNS returns: 151.101.1.195
↓
Browser connects to that server

3. What Happens When You Enter a URL

Let’s say you visit:
https://dev.to

Several things happen behind the scenes.
Step 1 — DNS Lookup

Your browser asks a DNS resolver:
“What is the IP address for dev.to?”

The resolver returns the server’s IP.

Step 2 — TCP Connection

Your browser establishes a connection to the server using TCP (Transmission Control Protocol).

TCP ensures:

Data arrives
Data arrives in order
Missing packets are retransmitted

This step is often called the TCP handshake.

Step 3 — HTTPS Encryption

If the site uses HTTPS (most do), the browser performs a TLS handshake.

This step:

Verifies the server’s identity
Establishes encryption
Protects the data being transmitted

Now your communication is secure.

Step 4 — HTTP Request

Your browser sends a request like this:

GET / HTTP/1.1
Host: dev.to

This is the HTTP protocol, which defines how browsers and servers communicate.

Step 5 — Server Response

The server processes the request and sends back a response:

HTTP/1.1 200 OK
Content-Type: text/html

Along with the HTML of the webpage.

Your browser then:

Parses the HTML
Downloads CSS
Downloads JavaScript
Renders the page
And the website appears on your screen.

4. How Data Travels Across the Internet

Data doesn’t travel as one big chunk. Instead, it is broken into small packets.

Each packet contains:

Source IP
Destination IP
Data payload
Packet number

Routers across the internet decide the best path for each packet to reach its destination.

Think of it like sending multiple envelopes through different postal routes that all arrive at the same house.

5. The Role of Servers and Data Centers

Websites live on servers inside data centers.

These servers run software like:

Web servers (Nginx, Apache)
Application servers
Databases

Large companies operate massive data centers around the world to ensure:

High availability
Low latency
Redundancy

6. CDNs Make the Internet Faster

To make websites load faster globally, companies use Content Delivery Networks (CDNs).

A CDN stores cached copies of content in servers located around the world.

Instead of requesting a file from a server in another continent, you may receive it from a nearby edge server.

This dramatically reduces latency.

7. A Simplified Flow

Here’s the entire process summarized:

User enters URL
DNS finds IP address
Browser establishes TCP connection
TLS handshake secures connection
Browser sends HTTP request
Server sends HTTP response
Browser renders the webpage

All of this typically happens in milliseconds.

Final Thoughts

The internet may seem complex, but at its core it’s built on a few fundamental ideas:

IP addresses identify devices
DNS maps names to IPs
TCP ensures reliable data delivery
HTTP allows browsers and servers to communicate

Understanding these layers helps developers:

Debug networking issues
Optimize performance
Build better distributed systems And once you see the mechanics behind it, the internet becomes a lot less mysterious.

What Working With Git Actually Taught Me About Collaboration

Elizabeth Omito — Mon, 23 Feb 2026 22:37:18 +0000

When I first learned Git, I saw it as a set of commands:

git add
git commit
git push
git pull

It felt procedural — just steps to move code around but once I started working on real projects, I realized Git isn’t just version control. It’s structured collaboration.

1. Commit Messages Are Communication
At first, my commits looked like this:
“update”
“fix”
“changes”

Later, I understood that commit messages are part of the project’s history. A good commit message answers:
What changed?
Why did it change?

Clear commits make it easier for teammates (and future you) to understand the evolution of the codebase.

2. Pull Before You Push
One practical lesson that stuck with me:
Always git pull before git push.
Not doing this led to conflicts and unnecessary friction. Pulling first ensures you’re building on the latest version of the project, not overwriting someone else’s work.

It’s a small habit with big impact.

3. Merge Conflicts Aren’t Errors — They’re Signals
The first time I saw a merge conflict, it looked like the code was broken but technically, Git was doing exactly what it’s designed to do:
It detected overlapping changes and paused the merge to let me resolve them intentionally.

Conflicts aren’t failures. They’re checkpoints that force alignment.

4. Smaller Changes Reduce Risk
Large, unstructured commits make reviewing and merging harder.
Breaking work into smaller, focused commits makes collaboration smoother and debugging easier.

This changed how I structure my work.

What I Learnt From My First Go Project: Go Reloaded

Elizabeth Omito — Fri, 06 Feb 2026 13:48:39 +0000

When I first started learning Go, I thought I understood the language.
I knew the syntax, I knew the logic, and I thought writing small programs would be easy.
Then I started Go Reloaded.

What Go Reloaded Was
Go Reloaded was my first “real” project in Go — not just following tutorials, but actually building something and making it work.
It was simple on the surface: output formatting, string handling, and writing a few functions.
But simple turned out to be deceptively hard.

The Moment I Got Humbled
I thought my code was perfect… until I ran the tests.
The output I got was:

it was the best of Times , it was the worst of TIMES,

whereas the expected output was:

It was the best of times, it was the worst of TIMES,

One tiny comma. One small space. And the test failed.

It was frustrating, but it taught me something crucial: precision matters. Computers don’t guess what you meant — they only care what you actually wrote.

What I Learned
From Go Reloaded, I learned:
-Small mistakes, like punctuation or spaces, can break everything.
-Writing code carefully matters more than writing it fast.
-Debugging is as much about reading the test as reading the code.
-It was humbling, yes, but also exciting. Each mistake became a lesson.

This project set the tone for all my future Go work. After Go Reloaded:
-I started reading test failures carefully.
-I paid more attention to formatting and data handling
-I became more patient and methodical

Go Reloaded was more than just code — it was my first taste of learning in public.

Final Thought
Sometimes the smallest projects teach the biggest lessons.
Go Reloaded taught me to slow down, pay attention, and embrace the little mistakes because that’s where growth happens.