DEV Community: Ali Ahmad

Journey before destination

Ali Ahmad — Wed, 04 Nov 2026 20:05:03 +0000

Journey Before Destination

I got into software engineering because I enjoyed it. I enjoyed the process of learning, the feeling of writing something and knowing that those sets of instructions were successful in achieving whatever goal they were set out to achieve, and that they did exactly what was needed.

Sometimes, things did what was needed but not in the way you expected. For many of us, it didn't matter how something worked as long as it worked. For a crazy few of us, however, it did. So we set out to figure out why something worked when we expected it not to, and then, being the crazy folks we were, we wanted to change that working code and break it. That sounds quite ridiculous if the thing being made wasn't software but some sort of physical object. It would be crazy to break a physical thing after you've made it and it works. But that's what software allowed us to do. We could experiment as much as we wanted, as long as we had the time.

Now, with the current world of AI-assisted and agentic development, or whatever fancy, investor-friendly term you want to use for it, it seems like all the fun is gone. Yes, you're achieving results, and at quite a fast pace, but where is the fun of losing your head over a config that isn't working for two days, only to find out that the issue was a character in the wrong case?

For me, the most memorable moments in my software engineering journey have been the ones where I spent a lot of time finding the root cause of an issue or figuring out a solution, followed by that hurrah moment when it finally worked the way I wanted it to. These weren't necessarily the most glamorous things you'd put on your CV. They may or may not have had enough business impact to look shiny enough for recruiters, but the journey of solving them was fun and satisfying because you learned so much about whatever system or context you were dealing with.

With AI, that whole journey seems to be reduced to almost nothing. You give it a prompt, wait a little, and there it is: a solution that either works or doesn't. Then you move on to giving it another prompt for the next JIRA ticket or asking it to solve the same problem in another way.

It feels like you've been riding horses, carriages or cars on your journeys, depending on the road, but now someone has just invented teleportation. Except it's not a perfect kind of teleportation where you know exactly where you're going to end up. It's more like the Floo Network from the world of Harry Potter. You say where you want to go, and the Floo Network takes you there, but sometimes, instead of a sandy beach, it drops you in the middle of a sandy desert. Now, there's no need to worry. You can ask it to take you to the correct beach with a little guidance, or ask it to take you home so you can start again, as long as you can afford it.

But the main thing to worry about is: where is the fun? Where is the journey? Would I want to land directly on the beach, or would I rather get there by train so I can watch the landscapes change along the way, look at the buildings in the cities, and see the sky go through its various phases?

One of my favourite memories ever is a trip to a mountain-top lake formed by a glacier. The reason I have such fond memories of this trip is the journey to get there: travelling along a small, dangerous path winding around mountains in a questionable jeep that somehow kept running on prayers alone. Then came the hike to the top, and when I finally reached it, the view was absolutely breathtaking.

If I could have teleported there instead, I would probably have looked at the lake, said "Nice lake", taken a picture and teleported back home. Then I would have forgotten about the place.

What I'm trying to say is that the journey part of software engineering seems to be diminishing, if not disappearing completely. Now, you just get the results, have a discussion about whether you like them or not, and then move on to the next ticket to repeat the cycle.

I don't want to argue that things shouldn't continue this way. We know AI is here to stay, and there's no going back. But the question is: will we ever enjoy this journey the way we used to?

I guess this is where I'll end this piece, leaving you with these words from Kaladin Stormblessed:

"Life before death, strength before weakness, journey before destination."

AI as a Coding Tool: A Mixed Experience

Ali Ahmad — Sun, 30 Mar 2025 07:29:44 +0000

Even though AI has been a hot topic in recent times, I had been reluctant to use it in my work as I have always trusted my own research instead of getting an answer directly from someone or something. Now this does not mean I did not use AI at all, I was keenly using it for improving documents, emails or other written content where I found it very helpful in getting ideas and correcting grammar. Although I did not like how long the suggestions were from ChatGPT because I always prefer to get straight to the point, I did however find it useful to pick some words or sentences from the suggestions to make my writings better. So in terms of writing I found the best utilization of the tool was to get suggestions and then write in my own terms taking the suggestion and using what I like instead of copy pasting the whole paragraph from ChatGPT which will contain a thousand adjectives around instead of coming to the point.

Now getting back to coding, I was skeptical of using this tool but I decided to experiment with it for one particular task that involved writing some automated tests. What I learned from this experience was to not blindly rely on the information provided by AI systems but to use them as a tool. In short, I went into an approach that was confirmed by ChatGPT to work, trusting that I wasted many hours trying to fix non existent issues when the main issue was the approach. The only way I got to learn that the approach was not possible was when I did my own research. In the end however the AI did recommend some solid alternatives which I ended up implementing and successfully completed my goals. Still this was not a very straightforward process. In the following sections I go into more technical details of the overall experience.

The goal of my task was to write some automated tests for an API endpoint that returns a list of products. The tools I was using for this purpose were Jest and Typescript. This would appear to be a quite simple task if anyone has worked on similar things, the idea would be to define a test case in which you call the API endpoint and then loop through all the products and add the tests for each of them.

Sounds quite straightforward, but for me it was not quite what I wanted. Adding all this logic in a single test case would cause the test to stop on the first failure it finds and then we would not get a complete picture of all the products as I would have liked. My idea was to define multiple tests that would run for each product and at the end we would get a nice overview of any issues encountered with any individual product and we could then track the issue easily because the test description would mention the product ID.

So for comparison in terms of code, below is what would be the simpler approach:


describe('GET /api/products', () => {
  test('should return a list of products', async () => {
    const response = await request(app).get('/api/products');

    expect(response.status).toBe(200);
    expect(response.body.products).toBeInstanceOf(Array);
    expect(response.body.length).toBeGreaterThan(0);

    response.body.forEach((product: any) => {
      expect(product).toHaveProperty('id');
      expect(product).toHaveProperty('name');
      expect(product).toHaveProperty('price');
    });
  });
});

What I wanted to achieve was to write some more organized tests like this:

describe('GET /api/products', () => {
  const products = [];
  beforeAll(() => {
    const response = await request(app).get('/api/products');
    if (response.status === 200 && response.body.products) {
     products = response.body.products
    } else {
      throw new Error('Something went wrong in the API response');
    }
  });
  describe.each(products)('validating product with id %p',  (product) => {
     test('It should have a name', () => {
       expect(product).toHaveProperty('name');
     });

     test('It should have a price', () => {
       expect(product).toHaveProperty('price');
     });
  });
})

The challenge here was to see if it is possible to define tests in this sort of dynamic data where we first load the result of the API endpoint and then define the tests. Here is where I decided to use ChatGPT. I went and presented my theory of using test.each from Jest on dynamic data that was loaded in a beforeAll block and asked the AI if that would work and it quickly responded that yes it should and gave me a boilerplate to use. I was happy with this and started using parts of the boilerplate to write my test cases. Once I was done I happily hit the run tests command and waited to see the response.

The output I got was the always dreaded cannot access property of undefined. Seeing this was not much of a bummer as any engineer working with JavaScript would have encountered this issue millions of times. So I went ahead and searched for where the issue could be in the code. The thing that I could not wrap my head around was that the issue seems to be in the object which contains the response of the API. This sent me to a detour trying to figure out if the API is working and if I am accessing the correct properties. I tried many things to figure this out but could not find the issue. What clicked at the end was when I tried initializing the variable I was using to store the API result with an empty array and then running the tests. Now Jest returned a different but more confusing message to me stating no tests were defined.

This was quite strange again and since I had trusted the AI I believed this should have worked. I tried a few different iterations of loading the API data in different ways, playing with beforeAll and async/await statements but nothing seems to be working.

After wasting many hours I decided to do some research I would have done originally without the use of AI and lo and behold within the first few results of my Google query I stumbled on a GitHub issue in the Jest repo discussing tests on dynamic data, from which I came to understand that Jest does not support this sort of thing. The way it works is that it will first go over the test file to figure out the number of tests to execute but since I was using an empty array which was supposed to have the list of products after getting the result from the API, Jest assumed there were no tests defined.

The next step I took was to communicate this to the AI that this is not supported after which it politely apologized and recommended alternate approaches to solve the problem, one of which was to put everything in a single test block which I wanted to avoid from the start. But the other solution was quite helpful, which was to preload the API data before executing the tests which is supported by Jest in terms of executing a script before running the test. I quite liked this approach and the AI recommended storing the API response in a JSON file and then loading the data in the tests. But here again ChatGPT made a mistake which I quickly realised this time. The AI recommended in its generated code to read the JSON data from the file in a beforeAll block but since this would be loaded at runtime we would run into the same issue as before where Jest would not know how many tests to run.

At the end I used a simple import statement to load the JSON data at the top of my tests file, in addition to this I had configured Jest to run a custom script which would call the API endpoint and write the response to the JSON file that we import in the tests. This way Jest finally considered the data as static and was able to calculate the number of tests to be run based on the length of the list of products returned by the API.

All in all this was a very mixed experience for me using AI as a coding tool, on one hand I was frustrated and annoyed at being led to believe that an approach would work and then wasting many hours on it but then also when I explained the issue with it’s own suggestions to the AI, it was quickly able to give me an alternate solution that worked and might have taken me some time to figure out otherwise.

The conclusion I got from this is that AI is a powerful tool for helping with coding but I would be as much skeptical of some of the answers it provides for more complex tasks as I am of humans. Maybe it will improve and take over my own job someday, it is a scary thought but that is life, it throws stuff at you and you have to learn to adapt. I guess we should all start preparing for backup careers, I am thinking of becoming a private chef. Otherwise I am pretty hopeful there would be work for me in fixing badly managed codebases written by AI in the future 🙂