DEV Community: Fayaz

I Won a Writing Challenge That I Almost Didn't Publish!

Fayaz — Mon, 24 Aug 2026 17:24:53 +0000

All praise to almighty God, and thanks to Google and the DEV Team, a while back, I won the Google Cloud NEXT '26 Writing Challenge!

Google Cloud NEXT '26 Winners

Jess Lee for The DEV Team

May 7

Congrats to the Google Cloud NEXT '26 Writing Challenge Winners!

#devchallenge #cloudnextchallenge #googlecloud

2 min read

A big congrats to all the other winners of this challenge. 🥳

The "interesting" thing is, I almost didn't even publish the post! 😬

I was running behind schedule and I still had too many things to say. I wanted the post to be perfect! But then I remembered the saying:

Perfection is the enemy of good enough.

So I focused on a specific topic, and completed writing right around 20 minutes before the deadline.

And just when I wanted to press the Publish button, I thought, why don't I check the Challenge page and see how much time I have left.

To my utter shock, the DEV Challenge page was showing the status: ENDED!

For a minute there, I thought I must have miscalculated the deadline based on my time zone, but then I got my confidence back after double-checking the deadline and timezone conversion.

At that point, there was no time to confirm with the DEV Team, so I just published the post first, and then wrote a comment on the Challenge announcement post.

Long story short: it was showing me the ENDED status because of a bug.

Thanks @jess for those quick responses! 🥰

Phew! Man, was I ever glad that I went through with publishing the post!

Obviously, after becoming one of the winners, I was totally thrilled, and in a way, gained a few pleasant lifelong lessons:

Never give up!

Ship, even if it's not perfect.

Hope my story will motivate others to publish more.

If you liked the post, here's another real-life story where I learned a few more lifelong lessons - and this time, the hard way!

Summer Bug Smash: Smash Stories 🐛🛹

Fayaz

Aug 24

Why my biggest embarrassment was also one of my greatest learning experiences in Programming!

#devchallenge #bugsmash #programming #performance

10 min read

Why my biggest embarrassment was also one of my greatest learning experiences in Programming!

Fayaz — Mon, 24 Aug 2026 06:29:53 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The background

This happened almost twenty years ago, in the year 2006, back in my undergraduate days, when I was still studying CSE - I participated in my first and only International Collegiate Programming Contest (ICPC), which was then known as ACM-ICPC.

I was, and still am, one of those programmers who like to take it slow, with full clarity, and try to completely grasp the concepts all by myself before jumping into implementation. As a result, I never was competitive programming contest material!

So then, why did I participate in that contest?

Well, one fine morning, I was working on a project in our university's computer lab, and two of my friends came to me and said, "We want to participate in the upcoming ICPC that our university is hosting, and we want you to join us!"

They even wanted to make me the team lead! I was hesitant at first, but then I thought, "Why not? It will be a good learning experience!" So I agreed to join them. Except for the team lead part, of course, that would have been a bit too much for me, given my lack of interest in competitive programming.

A bit more about my own background

I've never publicly shared this story before, especially because of the embarrassing part of it, but I think it's way past time to share it now, as I feel that it can be a good learning experience for others.

To make sure readers understand the context of my embarrassment, I need to give a bit more background about my programming experiences up until that point.

I started my Bachelor in Computer Science and Engineering (CSE) in 2002, at North South University and I was introduced to programming only in the first semester. Before that, I had no idea what programming was, but I found it interesting from the very first day!

C was my first programming language, but it was only part of a single credit lab course, which ended merely in three lab sessions, one and a half hours long each! So my real taste in programming began in the second semester, with the course named "Introduction to Object Oriented Programming in Java" - if my memory serves me right.

Around the middle of that second semester, there was an intra-university solo programming contest, and I participated in it. I was able to solve three out of six problems, which landed me third place in that contest! I was very happy about that, and it gave me a lot of confidence in my programming skills. But after that, outside my regular course curriculum, I became more interested in math, robotics and software development in general. For some reason, competitive programming never really attracted me that much.

That said, since I was attending that ICPC team contest anyway, I did try to prepare for it for a while. Part of that preparation was going through some problem sets from previous contests. As a CSE student, I was already familiar with most of the algorithms that were needed to solve those problems, so all I needed to do was to practice enough problems to be able to solve them quickly during the contest. We didn't get much time to prepare, so we thought it would be best if we participated in an actual contest before the main event.

Fortunately for us, there was an online programming contest hosted by Topcoder that was happening around that time. That was a solo contest also known as SRM (Single Round Match). All three of us participated in that contest, and all of us were able to solve two out of three problems individually, which was a good result for us.

So, from that preparation, we were expecting to solve at least 50-60% of the problems in the main contest! We weren't expecting to win, but we were hoping to do well enough to be recognized!

As a straight-A student, that was a very basic expectation for me, and I was very confident that I would be able to achieve that. But as it turned out, I was in for a big surprise!

The embarrassment

Now that all the background is out of the way, let me get to the embarrassing part of this story:

We ended up solving ZERO problems in the main contest!

Yes, you read that right - ZERO problems! We were not able to solve a single problem in that contest, and we ended up at the very bottom of the scoreboard!

Doomsday!

Every religion has a doomsday, and if programming were a religion, then that contest was our doomsday!

As I said before, I thought it would be a good learning experience, and I was right about that eventually, but none of us were expecting this sort of devastating learning experience!

Out of ten problems, we were able to solve none! We were not even able to solve the easiest problem in that contest, which was a very basic math problem. I still remember that problem somewhat, and I can still solve it in my head without much difficulty. But during that contest, we were not able to solve any of them!

I clearly remember, the moment I finished reading problem A (the very first problem), I knew that was the easiest problem in the contest.

In every ICPC, usually there's one problem that is very easy, as far as programming contests go, and it's expected that most teams will be able to solve that problem. The first one is not always the easiest, but in most cases, it is.

So I started solving it and probably within the first 5-6 minutes, I submitted my solution. But to my surprise, it was rejected! And the reason was given: "Memory Limit Exceeded". I was shocked! I had never encountered that error before, not in the practice problems we solved, and not in the past two contests I participated in!

It's not that I didn't know what that error meant, but for that particular problem, the input was really straightforward, and there was no way that my solution could have exceeded the memory limit, or so I thought! I was very confused, and I tried to figure out what went wrong, but I couldn't find any issue with my solution. So I submitted it again with some improvement in the algorithm, and it was rejected again for the same reason!

No matter what I did, I was not able to solve that problem, and I was not able to solve any of the other problems either! All three of us kept getting the same error, for all the problems we attempted to solve! We were completely baffled, and we had no idea what was going on!

The contest was four and a half hours long, and we gave up after trying for almost three hours! We were completely demoralized, and kept thinking there must be something wrong with the contest system, or maybe it was about solving those problems more efficiently. But no matter what we tried, we could not figure it out!

After we gave up, we spent the rest of the time gossiping among the three of us, trying to have some fun, as our last unsuccessful attempt to salvage some dignity from that contest.

And right when there were only a few minutes left in the contest, suddenly something clicked in my mind! OMG! I realized what the problem was!

The Aha moment!

Along with the computer, the contestants were allowed to bring some programming or algorithm books, and a pen-drive with some code snippets in it.

To solve the problems faster, the night before the contest, we wrote some code snippets for some common input and output handling - like taking inputs from the console (Standard Input), taking inputs from a file, printing outputs to the console (Standard Output), printing outputs to a file, etc. following common programming contest input output patterns. We wrote those snippets in C, and we were using those snippets in our solutions.

But the problem was: we were taking all the input lines into an array all at once, and then processing the array to get the result based on the problem statement, and then concatenating the result into a single string, and then printing that string as the output. That was a very inefficient way of handling input and output, and it was causing our solutions to exceed the memory limit!

However, since we were only focusing on solving the problems, we didn't realize that our prewritten input and output handling snippets were causing the problem! We were so focused on solving the problems that we didn't even think about the input and output handling part of our solutions!

Sample Code

As it happened long ago, I don't have the exact code snippets we used back then, but I can give you a rough idea of what they looked like.

1. The Flawed Code (Memory Limit Exceeded)

For example, in this version, we preallocated giant arrays to read all input numbers into memory before processing. Then we processed all formatted output strings in another huge array before printing anything to standard output.

With 100,000 per test case across up to 110 test cases, this instantly exceeded the judge's memory limit.

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

#define MAX_NUMBERS 100000
#define MAX_LEN 25

/* 
 * Flawed approach: Pre-allocating giant arrays to store all 
 * inputs and outputs in memory before printing.
 */
char input_numbers[MAX_NUMBERS][MAX_LEN];
char output_buffer[MAX_NUMBERS][MAX_LEN * 2];

void print_differing_suffix(const char *start, const char *end, char *out) {
    int i = 0;
    while (start[i] && start[i] == end[i]) {
        i++;
    }
    sprintf(out, "%s-%s", start, end + i);
}

int main() {
    int N;
    int case_num = 1;

    // Buffer inputs and outputs across test cases
    while (scanf("%d", &N) == 1 && N != 0) {
        int input_count = 0;
        int output_count = 0;

        // Store ALL input phone numbers into memory first
        for (int i = 0; i < N; i++) {
            scanf("%s", input_numbers[input_count++]);
        }

        // Process stored inputs into output buffer array
        int i = 0;
        while (i < N) {
            int j = i;
            // Check for consecutive phone numbers
            while (j + 1 < N && atoll(input_numbers[j + 1]) == atoll(input_numbers[j]) + 1) {
                j++;
            }

            if (j > i) {
                // Consecutive sequence range found
                print_differing_suffix(input_numbers[i], input_numbers[j], output_buffer[output_count++]);
            } else {
                // Single standalone phone number
                strcpy(output_buffer[output_count++], input_numbers[i]);
            }
            i = j + 1;
        }

        // Print header and buffered outputs all at once
        printf("Case %d:\n", case_num++);
        for (int k = 0; k < output_count; k++) {
            printf("%s\n", output_buffer[k]);
        }
        printf("\n"); // Blank line after each case output
    }
    return 0;
}

2. The Corrected Code

The proper approach should've been to read, process, and print one line at a time, rather than keeping the complete input and output in memory. In other words, we should've never built a giant concatenated output buffer before flushing it to stdout.

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

#define MAX_LEN 25

/* 
 * Corrected approach: Helper function to print range directly 
 * to stdout without allocating output buffers.
 */
void print_range(const char *start, const char *end) {
    int i = 0;
    while (start[i] && start[i] == end[i]) {
        i++;
    }
    printf("%s-%s\n", start, end + i);
}

int main() {
    int N;
    int case_num = 1;

    // Process case by case using streaming I/O
    while (scanf("%d", &N) == 1 && N != 0) {
        printf("Case %d:\n", case_num++);

        char start_num[MAX_LEN], prev_num[MAX_LEN], curr_num[MAX_LEN];
        long long prev_val = 0, curr_val = 0;
        int in_range = 0;

        for (int i = 0; i < N; i++) {
            scanf("%s", curr_num);
            curr_val = atoll(curr_num);

            if (i == 0) {
                // First phone number of the test case
                strcpy(start_num, curr_num);
            } else if (curr_val == prev_val + 1) {
                // Phone number is consecutive, extend current range
                in_range = 1;
            } else {
                // Consecutive sequence ended; output range or single number immediately
                if (in_range) {
                    print_range(start_num, prev_num);
                } else {
                    printf("%s\n", start_num);
                }
                // Start tracking new sequence
                strcpy(start_num, curr_num);
                in_range = 0;
            }

            strcpy(prev_num, curr_num);
            prev_val = curr_val;
        }

        // Output the final range or single number for the current test case
        if (N > 0) {
            if (in_range) {
                print_range(start_num, prev_num);
            } else {
                printf("%s\n", start_num);
            }
        }

        printf("\n"); // Blank line after each case as required by problem specification
    }
    return 0;
}

Lessons learnt

We thought that programming contests, and programming in general, were all about solving problems very efficiently, but we learned that, in real life, user input and output handling is also a very important part of programming, and it can make or break your solution! We learned that we should always be careful about how we handle input and output, and that we should never assume that the input will always be small enough to fit in memory, or that it will always be in a format that we expect.
We learned that we should always test our code against realistic input and output scenarios, with edge cases.
We learned that, sometimes, in programming, taking breaks and looking at the problem with a fresh set of eyes is essential to find trivial mistakes that we might have otherwise overlooked, while being too focused on the problem, the solution and the efficiency of it.
We learned that, in real life, failure doesn't mean the end of the world, and that we should always be ready to learn from our mistakes, and that we should never give up when it gets tough! As the proverb says:

When the going gets tough, the tough get going!

While trying to solve the problem after the AHA moment, we realized that we should've used a version control system like Git to keep track of our solutions, so that we could easily go back to a previous simpler version of our code and fix the input/output handling part without having to rewrite the entire solution from scratch, out of all the jumbled code we had written at the later part of the contest to make them unusually efficient! Had we used git, we probably would have been able to solve at least one problem in those last few minutes of the contest, and we would have been able to salvage some dignity from that contest!

The happy ending

After that embarrassing event, we three attended another programming contest, the last one in our life, as a team.

It was not an ICPC, but it was a prestigious inter-university programming contest nonetheless.

We secured 2nd place in that one. 🏆

And last but not least, I started my first job as a Software Engineer a week before my last programming contest. It was a students' contest, but since I was still a student when I registered for it, they allowed me to participate! 😇

Conclusion

I sincerely hope that this story will help others avoid making the same mistakes we made, but more importantly, I hope that you'll learn to rise up from failures - own them, learn from them, and use them as stepping stones to future success!

Disclaimer

I used AI to help with grammar and spelling corrections, but the story is genuine, and the main write-up is entirely my own.
Code snippets above are not the exact code snippets we used back then. They are AI (Gemini) generated rough approximations of what they would look like. So please take the story as the lesson, not the code snippets.
The cover image is AI (Gemini) generated.
I wrote the entire thing from memory. So, although the overall story is real, a few minor details here and there may not be!

References

The Actual Problem Set. I found it after deeply looking for it in the Wayback Machine. Salute to the Wayback Machine for preserving this problem set for so long! 🫡
My Topcoder Profile after attending the only online programming contest (SRM) before the main contest. Thanks to Topcoder for keeping my profile for twenty years! 😍

I need a new kind of Open Source Software License: "AGPL Pro Max"

Fayaz — Mon, 15 Jun 2026 20:05:48 +0000

As far as I know, AGPL doesn't cover Large Language Models.

I think it should, but it doesn't.

Going forward, we need a new kind of Copy Left License for Open Source Software - something that covers LLMs as well.

I mean, your LLM can be trained with my Open Source Software, but only if it's made Open Source as well!

I'm calling it AGPL Pro Max! 😎

Someone please give it a better name, and make it popular among developers. 🙏🏼

Question: Does something like this exist already?

If so, then what is it?
If not, then why not! 🤷

FayazFollow

A Software Engineer who is NOT afraid of being replaced by AI, loves coding & writing without using AI, while still enjoys using it from time to time; and values human life and dignity above all else.

New AI Model Quality Check Flowchart.

Fayaz — Sun, 14 Jun 2026 18:36:38 +0000

Is it banned by any Government?

Yes = Good Quality
No = Bad Quality

😁🤷🙏

FayazFollow

Don't always push the EASY button!

Fayaz — Mon, 08 Jun 2026 14:54:45 +0000

1. Use it 🧠 or lose it!

BRAIN ≠ BR AI N

2. If AI helps you to stay ahead of the curve 📈

Then use it when you have to, but be smart about it!
Think long term, strike the balance 🤔
Don't lose your skills by always pressing the EASY button!

FayazFollow

You'll not be replaced by AI if ...

Fayaz — Sat, 30 May 2026 03:23:59 +0000

There are many reasons why one may not be replaced by AI, not even by a possible future ASI.

Here's one reason that may just apply to you! ❤️

You'll not be replaced by AI if you can generate creative ideas faster than AI can implement them! 🫡🚀

Note for critics:

Current AI models (as of May, 2026) are not advanced enough to implement complex ideas without human interventions.

But even if a possible future Artificial Super Intelligence (ASI) implementation can do so, laws of physics like massive energy requirements, environmental concerns etc. will prevent the implementation to replace the work of Billions of people world-wide.

Our hardware advancement rate is far far slower compared to our software advancements.

We humans are far more efficient and compatible to planet earth compared to the hardware we've invented.

FayazFollow

Is it rare to crave for a Super Accessible ASI while also loving your own Human Creativity?

Fayaz — Thu, 28 May 2026 22:30:00 +0000

Am I one of the few "rare" developers who:

1. "Secretly" wants AI to finally succeed ...

... doing all the things AI CEOs continuously promise AI will be able to do, (but fail to deliver) - so that I can implement all those ten thousand ideas I thought I would never have enough time to implement; or will finally be able to implement my unique Open Source Everything App that will do everything from note taking, to time management, to publish blogs on my personal websites and/or social media, to email management, to password management ... everything in a deterministic way (not like the AI agent way) - all while everything being end to end encrypted, secure and private!

2. Yet, still loves the creative self ...

... writing code, poetry and articles by hand, even in a possible future where a super accessible ASI (Artificial Super Intelligence) exists, and even if it's 100% free with unlimited tokens, and even if it can be run locally on cheap hardware?

Or is this seemingly contradictory craving very common among developers?

Just wanted to know!

Note: No AI was ~~harmed~~ used to write this post. All the grammatical mistakes and the lack there of, are mine alone 😁

FayazFollow

AI fatigue is very real and people are fighting back!

Fayaz — Wed, 27 May 2026 19:45:09 +0000

Don't really like how CEOs are acting like AI is the solution for everything, it certainly is not!

Was watching this video today:

People need to realize: the reality of AI and the promise of AI - are two completely different things!

Treat AI like any other technology:

Act upon the reality, not the promise!

But people are fighting back, that's a good thing.
Hope we'll reach an equilibrium point soon!

My notes:

Don't let companies force you to use AI if it doesn't help your career in the long run.

Is your company simply using you as a Human Tool to train your AI Overlords that'll eventually replace you? - Fight back!

Gain and retain your knowledge and skills by doing (coding, designing, writing, reading etc.) yourself.

Use AI only if it doesn't violate the above two points!

Foundational human knowledge is not replaceable.

Your thoughts?

Disclaimers:

I have no affiliation with the author of the video. Only sharing it because I thought it's interesting for this community.

No AI was ~~harmed~~ used to write this post 😇

FayazFollow

Join the club! Note to self: - avoid FOMO - focus on one thing at a time - focus on something you can intellectually contribute to That's it! ❤️

Fayaz — Fri, 22 May 2026 08:55:06 +0000

Staying updated as unpaid homework

Harsh

May 21

I Used to Get Excited About New Tools Now I Feel Tired.

#ai #mentalhealth #programming #career

5 min read

The 2026 Agentic Era with Gemini Agent Platform: Surviving Cascading Failures and Runaway Cloud Bills.

Fayaz — Thu, 30 Apr 2026 06:45:48 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

The shift from simple AI pilots to fully autonomous digital task forces is officially here!

With the release of the Gemini Enterprise Agent Platform at Google Cloud Next '26, developers can now build, scale, and govern agents with the same rigor applied to mission-critical systems.

We are moving beyond standalone models and stepping into a brave new world where agents seamlessly discover and collaborate with each other using the Agent Registry and the universal A2A protocol.

But let us talk about the elephant in the room: What exactly happens when a tightly coupled multi-agent system goes off the rails?

Anatomy of a Cascading Failure

In a distributed agent architecture, you might have a Planner Agent generating data, an Evaluator Agent judging it, and a Simulator Agent running the scenarios. These agents rely heavily on one another. Didn't someone say:

introducing LLMs means our systems will start breaking in entirely new and unexpected ways!

Imagine a central agent accumulating massive amounts of uncompressed context during a complex simulation. Suddenly, it crashes because it exceeded the 1-million context token limit.

The immediate result is a severe cascading failure. Dependent agents are left waiting, causing unusually high latency and complete workflow stalls. The domino effect brings the whole interconnected application to a grinding halt.

Or perhaps something far worse can happen: if some of those dependent agents were constructed slightly wrongly, instead of just waiting for the crashed agent, they may even continue the Agentic loop and keep consuming LLM and API calls, causing a totally unexpected platform bill before you can check your Budget exceeded emails!

Failing Gracefully in a Multi-Agent World

Right now, Google Cloud offers features like Event Compaction to force agents to summarize workflows and avoid hitting those massive token limits. We also have Agent Observability to trace underlying reasoning loops and Gemini Cloud Assist to autonomously investigate logs and suggest proactive code fixes.

To survive the agentic era, developers must build in AI-specific resiliency.

When a core agent drops offline, dependent Agents must follow a safe fallback mechanism. This could mean returning a cached response from a previous memory session, skipping a non-critical evaluation step, or safely terminating the workflow while alerting a human operator.

Simply retrying a doomed tool call over and over can be a recipe for disaster!

What Google Cloud may Consider Building "Next"

We currently have fantastic guardrails like Agent Gateway for enforcing zero-trust identity policies, Cloud Assist for AI-powered debugging and Wiz integration for a living Security Graph.

However, to fully support resilient multi-agent environments, Google Cloud should consider introducing a few dedicated stability tools:

Agentic Circuit Breakers: A native feature in the Agent Gateway that detects when an agent fails repeatedly. It would cut off traffic automatically and return immediate fallback errors to prevent system-wide delays.
Dependency Graph Health Dashboards: While we have great open-standards telemetry, developers need live visualizations that instantly highlight deadlocks when agents are stuck waiting for each other in a multi Agent system. An enhanced Graphical Registry with Agent to Agent, Agent to MCP and Agent to API view may improve the overall understanding of the entire system greatly, especially when the users will end up having multiple multi-agent system for running their entire business.
Automated Fallback Routing: Native Agent Registry configurations that route prompts to a simpler, more deterministic backup model if the primary complex reasoning agent fails.

How the Agent development and Orchestration System could be more proactive like an actual Developer

While the agents are proactive in taking action and suggesting fixes, the keynotes do not explicitly demonstrate the agents actively asking the user clarifying questions to improve agent orchestration.

Currently, the system tends to take a user's prompt and immediately generate an architecture, such as instantly spinning up a main agent and a team of sub-agents in the Gemini Enterprise Agent Designer.

To make the Agent Platform act more like a senior developer, it could incorporate a "consultative phase" where it interrogates the user's prompt before orchestrating the agents (if necessary):

Interactive Architecture Reviews: Before deploying an Agent-to-Agent (A2A) network, the system could analyze the dependency graph and ask questions like, "I see the Simulator Agent depends heavily on the Planner Agent. Should we implement an Agentic Circuit Breaker here in case the Planner crashes?"
Prompting for Edge Cases and Limits: Instead of blindly accepting a prompt to build an agent, the system could act as a technical lead and ask, "You are giving this agent access to the live production database. What happens if it loops infinitely? Should we establish a hard Pricing Cap or token limit before I deploy this?"
Refining Orchestration Logic: If a user asks to connect multiple agents, the system might ask, "Do you want these agents to run in parallel to save time, or sequentially so that the Evaluator Agent can grade the Planner Agent's work first?"

By transitioning from simply executing instructions to actively interviewing the developer about constraints, error handling, and cost management, the platform could help prevent the exact types of cascading failures we observed in the keynote.

Controlling Costs: The Need for Pricing Caps

Operating agents safely requires careful attention to both infrastructure scale and token scale. As agents autonomously spawn other sessions and call multiple tools, an unhandled failure can become a massive liability.

When an agent fails, dependent agents might get stuck in an infinite loop of retries and hallucinations. This generates massive token usage very quickly. Implementing a hard pricing cap on individual agents, or a budget limit across the entire multi-agent system, is a critical financial failsafe.

If an agentic loop spirals out of control, a pricing cap would automatically suspend the agent once a specific dollar amount is reached. This ensures companies can innovate with autonomous task forces without the fear of waking up to unforeseeable, astronomically large cloud bills.

As we fully embrace this interconnected agentic era, blending strict technical guardrails with hard financial boundaries is the only way to build truly production-ready AI.

Let us build responsibly!

Computer Science was never about programming, it's about problem solving.

Fayaz — Mon, 11 Aug 2025 18:24:27 +0000

From the very beginning of our CS-101 course, we weren't just taught to write code; we were taught to design solutions. Solutions so sophisticated that, eventually, they are supposed to run without our involvement.

Today, with AI, that vision has almost breached our deepest intellectual work, and made many of us question the future of work itself!

Fayaz

Feb 3 '25

Predicting 2025 - A brave new world!

#devchallenge #newyearchallenge #future #ai

3 min read

So, should we use AI everywhere? 🤔

If it makes sense, yes, absolutely!

The use of AI can no longer be stopped anyway, so the only thing we can do is to regulate it for responsible use.

Should we fear that AI will replace us? 🫣

Not really!

Here is why:

1. AI will never become human:

It can calculate, build, optimize, and predict, but it can never be us. Which means, there will always be a need for us: our judgment, our empathy, our creativity.

Yes, the nature of our work will change, as it always has with technological advancements. But change does not mean irrelevance.

Religion tells us that even God "used" human involvement to shape human history.

Nature shows us that when even a more intelligent species emerges, all others don't simply vanish; they adapt, they evolve, and only those who can't evolve, vanish - but most of them survive in their own way, and some even thrive!

And to be honest, after all the hypes, current AI isn't even that intelligent, and the promise of an all knowing super AI model is just that, a vague promise.

I'll believe it when I see it. And even then, I don't think it's going to replace us for all the reasons mentioned above!

2. Experts will always use AI better:

Experts in a field will always have a far better edge over the layman. Besides, if you don't have expertise in a field like Software Development (especially Software Engineering), how would you know when AI makes mistakes?

Only experts in the field will know that, so companies will always need the experts for reliable and productive development.

3. Transfer of Responsibility:

Modern AI models sometimes work pretty well, and sometimes make mistakes - so, the question is, who is responsible when an AI model makes a terrible mistake?

The model itself?
The organization that made the model?
The company that's using the model?
The employee that's using the model?
Government?
UN?
Aliens?
God?

Of course that's just a rhetoric question.
We simply can't shift responsibility and accountability to an AI model!

If for nothing else, then because of responsibility and accountability that AI will not replace us, it can only enhance and change our nature of work - that's all.

Companies will have to recognize it soon, or will learn it the hard way.

So, as you see, the future isn't about competing with AI.

It's about using AI wisely, efficiently and responsibly to solve problems we encounter at everyday life, all while keeping our expertise intact - only this will probably allow us to tackle problems in a way that was once thought impossible.

Use Algolia MCP Server & VSCode GitHub Copilot to Find and Submit Unique Projects in Dev Challenges! ❤️‍🔥

Fayaz — Mon, 28 Jul 2025 06:03:05 +0000

This is a submission for the Algolia MCP Server Challenge

Introduction

Recently I've found myself participating in quite some Dev Challenges. I'm Loving it!

However, the problem is: Most of my Dev Challenge submissions are done on the weekends. That means by then, there are already many submissions.

That's great! But what's the point in working on something someone had already done! I mean, it's not always a bad thing, but wouldn't you rather work on something unique!

In comes Algolia MCP Server Challenge!

So I thought, would the Algolia MCP Server make it easy for me to check if what I'm going to work on is at least unique so far?

This is what this project is all about.

What I Built and How I Utilized the Algolia MCP Server

Installed Algolia MCP Server on VSCode with GitHub Copilot (Linux).
Developed a CLI Tool to Fetch dev.to Challenge Submissions using the Forem API.
Developed a Web Interface to check the Submissions locally.
Developed an MCP (Model Context Protocol) Server named dcs to get the Submission data in GitHub Copilot Agent Mode.
Then indexed that Challenge submission data in Algolia, using Algolia MCP Server, by simply asking:

#dcs fetch algoliachallenge tag submissions, get all the submissions from this tag, and add them to my Dev Challenges app in #algolia

Finally, asked GitHub Copilot in Agent mode if my project idea is unique!

Once I built everything, all I had to do was ask:

#algolia in Algolia Challenge did anyone submit something related to GitHub Copilot?

And there it was!

I didn't have to dig deep into all the submissions on dev.to
Didn't have to do any complex search

Just one single command to Algolia MCP server and the AI Agent took care of the rest!

In my mind, I've already won something from this challenge! 🚀

I'm sure other developers are going to love this technique, and future Dev Challenges are going to receive more unique submissions using similar solutions.

Who knows, may be dev.to will provide their own MCP server in the near future! 💫

Demo

The following GitHub repo has all the necessary code and instructions for:

Using GitHub copilot with Algolia MCP Server and DCS (Dev Challenge Submission) MCP Server
DCS CLI
DCS Web App

SweaDev / dcs

Dev Challenge Submissions

A modern web application for browsing dev challenge submissions from dev.to. This app consists of a CLI tool to fetch submissions, a React web interface to display them, and an MCP server for AI assistant integration.

Roadmap / Todo list:

More detailed hands on tutorial about using this project effectively.
Daily auto update of Challenge submissions.
Filtering out unrelated posts that uses the Challenge tags.
FullStack Web App with option to use your own LLM API key for unique project brainstorming.

Features

CLI Tool: Fetch, update, and manage submissions from dev.to using the Forem API
Beautiful Web Interface: Browse submissions with sorting and search functionality
MCP Server: Model Context Protocol server for AI assistant integration (GitHub Copilot, Claude, etc.)
Auto-refresh: Web app automatically updates when new data is fetched or removed
Responsive Design: Works great on desktop and mobile devices
Safe Operations…

View on GitHub

Key Takeaways

I've made the initial setup using vite and pnpm.
Then mostly vibe coded the solutions using GitHub Copilot in Agent Mode with Claude Sonnet 4. But I did have to do some work when Claude started to make mistakes. So it's not all vibe coded work.
Algolia MCP Server documentation doesn't provide instructions for Linux or GitHub Copilot, but with a bit of tinkering, I could make it work.

.vscode/mcp.json file:

{
    "servers": {
        "algolia": {
            "command": "${input:algolia_mcp_dir}/algolia-mcp"
        },
        "dcs": {
            "command": "${input:dcs_mcp_dir}/server"
        }
    },
    "inputs": [
        {
            "id": "algolia_mcp_dir",
            "type": "promptString",
            "description": "Path to the Algolia MCP directory",
            "password": false
        },
        {
            "id": "dcs_mcp_dir",
            "type": "promptString",
            "description": "Path to the dev.to Challenges MCP directory",
            "password": false
        }
    ]
}

GitHub Copilot's support for Algolia MCP Server is quite good!
Although, only Claude models support Algolia MCP Server in GitHub Copilot, GPT models don't support it! Gives 400 error.
That said, GitHub's own MCP Server works with GPT 4.1 in GitHub Copilot Agent Mode. Didn't have time to debug why Algolia MCP Server only works with Claude models. Perhaps Algolia team will work on this?

Overall, participating in this challenge was really a happy experience for me.

I hope other developers will also be benefited from this project. ❤️