AI Replaced Me -- Just Not the Way You Think

Muhammad Haris Javed — Wed, 15 Jul 2026 15:07:25 +0000

AI replaced me.

Not the way you think. I'm still a software engineer. But the work I used to do in the office? AI does that now. I got replaced... and became something else.

Let me explain with a story from the start of my career.

The best client in my early career

Early in my career at KNYSYS, I got the opportunity to work with a client building a Laboratory Information Management System (LIMS). Information systems were trending at the time, and I was excited just to be on the project.

Then I saw their requirements document.

It was the best spec I have ever received. It had:

Every entity described : down to the column names
Functionality attached to each entity : CRUD operations, GET/POST/UPDATE behavior, all spelled out
UI management and user roles : defined per screen, per role
The "why" behind every decision : not just what to build, but the reason it mattered
High-level tasks already broken down — I could pick one up and just start

And here's what made it truly great: no useless information. Nothing was missing, and nothing was extra. Every line earned its place.

The rhythm

The workflow was simple:

I pick up a task and build it
I deliver
Their team tests it
They send back bugs, feedback, or changes
I fix and move to the next task

It felt like a rhythm. Task by task, sprint by sprint and at the end, a real product existed.

Back then, I thought the developer was the hero of that story. I was the one turning documents into working software, after all.

The realization

Years later, I see it completely differently.

The genius of that project wasn't my code. It was whoever wrote that document. The person who took a messy, ambiguous business need "we need a system to manage lab information" and turned it into something so precise that a junior developer on the other side of the world could build it without confusion.

That skill was always the rare one. We just didn't have a name for how valuable it was.

The twist

Now look at my job today:

I became that person. I write the specs every entity, every behavior, every "why", with nothing missing and nothing extra.

We just call them prompts now.

And the developer I used to be the one who reads the spec and writes the code? That's AI.

The feedback loop flipped too. I used to deliver code and wait for the client's team to test it and send changes. Now AI delivers code, and I test it, find the bugs, and send the changes back.

Role	Then	Now
Writes the spec	Client	Me (it's called a prompt)
Builds the code	Me	AI
Tests & gives feedback	Client	Me

Same workflow. Same rhythm. I just switched seats.

"But nobody gives perfect requirements"

Here's a line I hear from some developers:

"If clients gave us perfect requirements, we'd deliver in a few hours. But nobody ever does."

Some developers says it like a complaint. I think it's the most important sentence in our industry right now.

Because think it through: if someone could write a perfect requirement, why would they need you? They'd hand it straight to AI and get their software.

The reason software engineers still exist is precisely that nobody can do this. Turning a vague human idea into a precise, complete, buildable specification deciding what matters, what's missing, what's ambiguous, what will break that was always the hard part of software engineering.

The code was never the product. The understanding was. AI just made that impossible to ignore.

What this means for you

If you're a developer wondering how to adapt, my honest advice from living through this shift:

Practice writing specs, not just reading them. That LIMS document is now the skill ceiling. Can you describe a feature so precisely that anything human or AI could build it correctly?
Get good at reviewing code you didn't write. Testing AI output, spotting the subtle bug, knowing when the architecture is wrong this is the new code review, and it's most of the job.
Own the "why". AI can generate any solution. Only you can decide which problem is worth solving and whether the solution actually solves it.

AI didn't replace me. It promoted me from the person who reads the spec to the person who writes it.

The question is: which seat are you sitting in?

Get good at reviewing code you didn't write. Testing AI output, spotting the subtle bug, knowing when the architecture is wrong — this is the new code review, and it's most of the job.
Own the "why". AI can generate any solution. Only you can decide which problem is worth solving and whether the solution actually solves it.

AI didn't replace me. It promoted me — from the person who reads the spec to the person who writes it.

The question is: which seat are you sitting in?

Have you noticed the same shift in your work? I'd love to hear how your day-to-day has changed. drop a comment.

good logging practice in backend

Muhammad Haris Javed — Sat, 12 Apr 2025 10:38:18 +0000

Logging is a crucial aspect of backend development. Effective logging allows you to monitor your application's health, debug issues, and understand user behavior. Poor logging, on the other hand, can lead to wasted time, difficult debugging, and security vulnerabilities. This article outlines some best practices for implementing effective logging in your backend systems.

Key Principles:

Log Levels: Utilize different log levels (DEBUG, INFO, WARNING, ERROR, CRITICAL) to categorize log messages based on their severity. This allows you to filter and prioritize information effectively. DEBUG is for detailed debugging information, INFO for general application flow, WARNING for potential issues, ERROR for actual errors, and CRITICAL for system-critical failures.
Context is King: Include relevant context in your log messages. This might include timestamps, user IDs, request IDs, affected resources, and any other information that helps pinpoint the source of an issue.
Structured Logging: Instead of free-form text, use structured logging formats like JSON. This allows log aggregation tools to easily parse and analyze your logs.
Avoid Sensitive Information: Never log sensitive data like passwords, API keys, or credit card numbers. This is a major security risk.
Centralized Logging: Aggregate logs from different services and servers into a central location. This simplifies monitoring and analysis. Tools like Elasticsearch, Logstash, and Kibana (ELK stack) or Graylog are excellent for this purpose.
Log Exceptions Properly: Don't just log the exception message. Include the stack trace and any relevant context that led to the exception.
Performance Considerations: Logging can impact performance. Avoid excessive logging, especially at the DEBUG level in production. Use asynchronous logging where possible to minimize blocking operations.
Use a Logging Framework: Leverage a logging framework like Python's logging module or similar frameworks in other languages. These frameworks provide built-in functionalities for log levels, formatting, and handlers.

Real-World Scenario:

Imagine an e-commerce platform. A user is trying to complete a purchase, but the payment gateway is experiencing intermittent issues. Without proper logging, debugging this issue would be a nightmare.

Poor Logging Example (Python):

print("Payment failed")

Good Logging Example (Python):


python
import logging

logger = logging.getLogger(__

DEV Community: Muhammad Haris Javed