The Old Engineering Reminiscence

It was in late 2019, as I was treading through my gruelling first year of Software Engineering career, writing the security framework of the first ever product I was building, my phone kept ringing from my dad at about 10:30pm. He had a serious tone on, asking why I still wasn’t at home when I was supposed to clock out at 8:00pm. This was before the pandemic taking over. Laptops weren’t allowed to be carried home and WFH was permitted only for emergencies and restricted to selected senior personnel. I had no immediate deadline to finish the task at hand, nor was I being tracked on a race to bonus bounties. It was the sheer determination in wanting to see the POST request to the authentication endpoint return a beautiful successful JSON with 200OK on Postman’s response console. The shape and the colour of the formatted JSON fascinated me in my early days. I spent about 30m thinking how detailed the response should look, and ended up with what my frontend could work with. Before I finally got off the chair, I tried the authentication workflow, had it successfully redirect to the dashboard, only to realise the cookie wasn’t being accepted by the backend on subsequent requests as an authorised user, and the data didn’t show up.

I spent the rest of the week working on it before I could eventually drag myself through the finish line. In hindsight, did it make sense to spend late that night at the office when I wasn’t going to finish it anyway? It probably didn’t, but it didn’t feel so when I finished it because I enjoyed crafting that code for the first time in a production grade application all by myself in the quiet of the evening. Debugging and ensuring a loophole isn’t hiding somewhere beneath those plausibly edge-case buggy authentication workflow written as an engineer who’s still halfway away from his first work anniversary was quite interesting and exciting. There’s a unprecedented dopamine hit from just making it work (isn’t that all we care for as beginners?).

Over the next six months (and during which time my father passed away), I would go on to write a small-sized framework to import about 30 Excel sheets with a single POST request, each sheet binding to its Spring Data entity based on the Java annotations I custom developed, and let my team go wild on mapping all the different entities and get the import to work across all of them. That was crazy 2 months trying to oil up the machinery, tighten the screws and fine tune how it must automatically transfer data from Excel to the database. In the process of getting this artifact out (along with the other areas of the application, meeting other projects’ expectations and dealing with personal turmoils), I navigated through moments of pressure, pain and triumph. A couple of years later when I would have gained much more experience than a rookie across clients and products, I looked at that code and asked myself “how’d I write all that by myself? But there are several improvements to be made. I should work on it over my free time.” I never touched that code again. But I enjoyed every moment I wrote it, putting in the arduous hours of reading through JavaDocs, GitHub references and Google/StackOverflow. I also remember my lead engineer saying at the time, “The code you’ve written gets the job done, but it’s quite complex other junior engineers may not understand and may not have good readability.”

The AI CodeGen Era

Readability. I’ll let us all catchup to the segue in a bit. Fast forward to today, we have novice engineers pulling off great feature work in two days that could have earlier been a week’s worth of work after hashing out the requirements, fixing our own code every 4 hours just because some other method has a different parameter or returns something that doesn’t fit, and several round trips with Product. We now focus on what’s the best model to manufacture large chunks of code at a single go, and how many agents to orchestrate in parallel to have a large feature implemented while we pull out our phones and scroll YouTube shorts. OpenAI and Anthropic (amongst others like Qwen and Deepseek) have immensely shape-shifted the Software Engineering landscape. Emphasis has been offset onto delivery velocity and frequency. Product and business suggest the expectation velocity too has increased, and Agile has a new definition and in colourful gradients seen with AI developed presentation patterns. But here’s the real challenge: deciphering the AI generated code and having to mentally map it to the requirements may not be so easy for human cognitive limits.. the readability concerns.

AI didn’t fundamentally alter the engineering lifecycle itself though, in my opinion. It made certain stages move faster, regardless of whether it improved the quality (quite a strong ongoing global debate at the time of this writing). In the agentic era, there is a particular significance to markdown files. They’re likely a drop-in replacement for the Functional and Technical Design documents that BAs and Architects once put several hours and even days into writing them. And followed by multiple rounds of reviews and baselining to push the final revision to downstream folks: engineers. That has changed with some-spec[.]md files. And do we have to really write these markdown specs by ourselves like the good old days? It’s perhaps a choice to make. We switch our Copilot TUI to Plan Mode, discuss the requirement, throw some rants at it when it puts in a wrong proposal, and order it to write up a markdown file that other agents can understand for implementation. And then the concurrence with the old process: pass it onto an engineer who can simply feed the design specification to the agent and let it have a go at it. They loop the agent until they are satisfied by what it produces.. unless they’re in a hurry. Do we have to mind about the code it generates when the UI does what it should and there’s code review on GitHub by Copilot and then followed by other humans? There are arbitrary ramifications sometimes, sure, but again we’re just a “we’ve broken something in the process, could you please fix it?” prompt away from getting that squared. Regression isn’t a new concept.. maybe it just has become more common than before. The bridge between the requirements and delivery hasn’t changed.. it shrunk so the supply chain didn’t take as long as it did before. Throughput has become higher as far as development velocity is concerned.. but if you factor in the variable of Quality that many of us so strive for, perhaps there’s a thick line there, blurred based on who sees it.

If you’re an engineer who loves to code but is deterred by the whole AI process, don’t be. If you’re a new engineer in the town elated by how AI is pulling off amazing features without you having to write code, don’t be. Let AI do its work of keeping your expectations and commitments meet at the workplace, but keep learning and researching. Regardless of where things go from here, be interested in learning more. Languages, frameworks, architectures, design patterns, etc.; there is always something new to learn and deep-dive into. With the way things are going, anybody can pull off a feature; if you want to be a standout person in a conference room, knowledge, skill and the confidence that comes out of those are quite important for your tech personality. Time will eventually reveal, as it always does with many transitional eras, how much of that matters in the long run.