TL;DR: Six months ago I published a Copilot-specific model guide. Almost every name on it has since been superseded. This mid-year update widens the lens beyond GitHub Copilot to every environment — Cursor, Codex, Windsurf/Devin, Claude Code, or a raw API — and gives each current model the same exhaustive best for / when to use / trade-offs / pro tip treatment. It covers the closed-source frontier (Anthropic, OpenAI, Google, xAI) and the open-weight surge (GLM, DeepSeek, Kimi, Qwen, MiniMax, Nemotron, Mistral) that has, this year, become genuinely production-grade.

Generated AI image by Google Gemini Nano Banana

Introduction

Back in January I wrote a guide to GitHub Copilot’s model picker — GPT-5, the early Claude 4 lineup, Gemini previews, and which to reach for when. That post aged in weeks, which six months on feels like the whole point of writing about this space.

Since then: Anthropic shipped Sonnet 5 and Opus 4.8, launched a new top tier (Fable 5), and had to pull that top model off the market for three weeks under a US export-control order before restoring it. OpenAI iterated through GPT-5.4, 5.5, and the GPT-5.6 “Sol / Terra / Luna” family, and merged its Codex and general-purpose stacks into one model. Google shipped Gemini 3.5 Flash but scrapped and rebuilt its next flagship from scratch. xAI turned Grok into a coding-first model co-trained with Cursor. And a cluster of open-weight labs — Z.ai’s GLM, DeepSeek, Moonshot’s Kimi, Alibaba’s Qwen, MiniMax, and NVIDIA’s Nemotron — closed the gap on the frontier to single benchmark digits while running at a fraction of the cost.

This time the post is not Copilot-specific. If you’re in Cursor, Codex, Windsurf, Claude Code, or straight through an API, the same models and trade-offs apply — only the interface changes. The discipline is the same as January: match the model to the task, not the task to whatever’s newest. There are just a lot more models now.

Generated AI image by Google Gemini Nano Banana

Introduction

You’ve learned to write better prompts. You’ve learned to structure context. Now it’s time to think about what turns a model into an agent — and what keeps that agent under control once it’s running.

What Is Harness Engineering?

In my previous article, I mentioned context engineering quite a bit and how it’s important for developers to master in this AI era we’re in. If you’ve spent time on context engineering, you already understand one truth: the quality of what you give an AI model matters as much as the model itself.

Harness engineering is the discipline that comes next — and it’s a bigger shift than it first sounds.

Context engineering answers what do I put in the prompt? Harness engineering answers a different question: how does the model actually act — calling tools, tracking state across steps, staying inside guardrails — and how do I control that?

Generated AI image by Google Gemini Nano Banana

Introduction

“Prompting is easy. Getting reliable behavior from an AI system is hard.”

If you’ve ever built or worked anything serious with LLMs, you’ve already discovered the truth:
hallucinations, drifting answers, and inconsistent behavior are not bugs — they are symptoms of bad context.

Here’s a number that should change how you think about this: developers in 2026 can fully delegate only 0–20% of tasks to AI agents — even though those agents are completing an average of 20 autonomous actions per run. The bottleneck isn’t model intelligence. It’s context quality.

In 2026, the most important AI skill for developers is no longer prompt engineering.
It is context engineering.

This post explains what that really means, and how developers can build AI systems that are predictable, grounded, and production-grade.

Generated AI image by Microsoft Bing Image Creator

Introduction

Practical prompts to stay cognitively sharp while using AI tools every day.

Earlier in the year, one of my personal breakthroughs working with AI is to help accelerating my learning and picking up new skills faster than I would spend hours and hours digesting tech documentation from engineering community blogs, manuals etc. That’s what I love all things about AI. It’s essentially an enhanced Google search - but running on steroids that we all come to accustomed this new ways of software engineering learning mastery.

But as I use it more and more, I also start to notice that it’s not just a tool that helps me learn faster. It can also be a tool that helps me learn less. When I reach for AI before forming my own hypothesis, accept generated code without tracing it, or skip the “why” and go straight to the fix — I’m not using AI as a tool. I’m outsourcing the thinking that makes me an engineer. Over time, debugging intuition, design judgment, and first-principles reasoning all quietly degrade.

So the lingering question beckons - are AI coding tools accelerating your learning and fulfilling your engineering curiosity? Or are they quietly replacing them altogher? The difference comes down to how you prompt.

Generated AI image by Microsoft Bing Image Creator

Introduction

As software engineers, we’re constantly seeking ways to streamline our workflows and boost productivity. GitHub Copilot CLI has emerged as a powerful tool that brings AI assistance directly into your terminal, transforming how we interact with code across different stacks. This comprehensive guide will walk you through setting up an effective AI-powered development workflow with GitHub Copilot CLI, whether you’re building front-end applications, back-end services, data pipelines, or cloud infrastructure.

Note: GitHub Copilot CLI is currently in public preview and features are subject to change. Always refer to the official GitHub documentation for the most up-to-date information.

What Makes Copilot CLI Different?

Unlike traditional code assistants, Copilot CLI is terminal-native and agentic—it doesn’t just answer questions, it can act as your coding partner. You can delegate tasks, and Copilot will autonomously execute them while you maintain oversight through explicit approval mechanisms.

Generated AI image by Microsoft Bing Image Creator

Introduction

GitHub Copilot now supports multiple AI models from leading providers including OpenAI, Anthropic, Google, and xAI, giving developers unprecedented flexibility to choose the right tool for their specific coding scenarios. Understanding the strengths and trade-offs of each model can significantly improve your productivity and code quality. This guide breaks down when to use each model and provides practical tips for getting the most out of GitHub Copilot in 2026.

Generated AI image by Microsoft Bing Image Creator

Introduction

Since my last post on setting local AWS Glue using Docker, one of the potential extensions I mentioned is to setup Github Actions CI/CD pipeline for it. In modern data engineering, testing cloud-native applications locally before deployment is very crucial for rapid iteration and cost efficiency. Thus, as part of this exploratory exercise, I want my CI/CD pipeline to achieve the following outcomes(in scope):

• Automate testing of AWS Glue jobs in a local environment
• Use Docker to containerize the Glue runtime
• Leverage LocalStack to simulate AWS services locally
• Integrate with GitHub Actions for continuous integration and delivery
• Ensure code quality with SonarCloud and Codecov

Not in scope for this pipeline:

• Terraform or infrastructure-as-code testing
• Deployment to actual AWS environments
• Advanced security hardening for enterprise compliance

This guide walks you through building very robust (if not production-ready) CI/CD pipeline using GitHub Actions that integrates Docker containerization, LocalStack for AWS service emulation, and comprehensive testing for AWS Glue jobs.

Generated AI image by Microsoft Bing Image Creator

Introduction

First off.

Happy New Year to all! Every engineer of various specialisations (ie front-end, back-end, data, devops, cloud, mobile, etc) would come to realise by now how much AI has heavily shaped and redefined our ways of engineering practices since ChatGPT made major headlines back in late 2022.

More than 3 years on with plethora of evolving AI tools at engineers’ disposals , I arrive with this conclusion.

“AI didn’t replace my love for software engineering — it gave it back to me.”

In 2016 (and beyond), being a software developer or engineer no longer means fighting every line of code alone.

It means having an intelligent collaborator that helps you think, build, refactor, document, test, and ship — faster and with more confidence than ever before.

For me personally, this shift became real the moment I subscribed to GitHub Copilot Pro for my own pet projects.

I reopened application repositories that I hadn’t touched in years, especially starting off with this one as an example. It’s a classic space invaders game written purely in Vanilla JS.

When looking into this repo for the first time, it came with my immediate reactions.

• Old ideas.
• Half-finished tools.
• Abandoned experiments.

And suddenly.

Using AI — instead of feeling overwhelmed — I felt energized.

Generated AI image by Microsoft Bing Image Creator

Introduction

As we bring 2025 to a close, software engineers like myself find themselves immersed in all things AI from every direction—left, right, and dead center: Medium blogs, AI forums like Rundown AI, AI meetups, etc.—all in a constant state of flux. The message couldn’t be clearer: ignoring AI is no longer an option. Those who resist embracing these tools risk falling drastically behind in an industry moving at lightning speed. The greatest folly isn’t experimenting with AI and making mistakes — it’s refusing to adapt at all.

But here’s the critical insight most engineers miss: it’s not about using AI; it’s about using AI systematically.

Generated AI image by Microsoft Bing Image Creator

Introduction

If you’re like me, you’ve probably experienced the frustration of developing any AWS applications in the cloud especially such as lambda, cloudfront, S3, etc using tools like SAM, CloudFormation etc.. Now that I’ve been delving into the world of data engineering, AWS Glue jobs is one of the main AWS data engineering tooling offerings, the frustrations in having to push Glue jobs directly in the cloud—waiting for job runs, nitty gritty AWS Glue binaries setup, dealing with slow feedback loops, and watching your AWS bill creep up with every test iteration. I’ve been there, and it’s not fun.

That’s why I built this local development environment. After experimenting with different approaches, I’ve put together a Docker-based setup that lets me develop and test Glue jobs on my laptop before deploying to AWS. The best part? It includes all the real-world components I actually use in actual cloud envs: Kafka for streaming data, Iceberg for my data lake tables, and LocalStack to simulate AWS services.