🧭 Finding Signal in the AI Noise - A Pragmatic Perspective

📢 The Noise

The AI hype is almost unbearable at times. Every day we are bombarded with the latest and greatest developments, all of them touted to revolutionize our lives in meaningful ways. As a software engineer, it might be tempting to bury our heads in the sand and stay the course with what we already know. It’s human to feel apprehensive about change, but dismissing AI won’t make it go away.

↔️ The Divide

In the last couple of years, AI has arrived at the party and made itself known. As with many contemporary technologies, blockchain and crypto as other recent examples, opinions in the engineering practice tend to be polarized.

In my experience as an engineer and also as an engineering manager I’ve witnessed that new technologies tend to be divisive. Opions range from the fundamentally opposed: those who will not and cannot accept AI as having a place in modern software development. On the other hand: we have the hype masters, those who take all the marketing hyperbole at face value.

Although it’s tempting to pick a side, there is no need to place yourself firmly on this virtual AI spectrum. Instead, try adopting a balanced and pragmatic mindset.

🧳 My Journey

My engineering background is rooted in “the fundamentals”: that is, I value well written code with clear intent, good testing practices, avoiding unnecessary complexity. I’ve come to value these over the years of working with different teams on many different projects.

I’m sharing this to illustrate that I had (and still have) firmly held belief that certain things work well and other things do not, and my initial stance towards AI was that of a skeptic.

My attitude towards AI began to shift whilst working on a personal project. Back in early 2023 when ChatGPT was relatively new it was a useful tool to help me reason about a low-level Bluetooth packet protocol that I was reverse engineering. I could have done this manually, but there is no doubt in my mind that it saved me time in finding patterns that helped expand my understanding of the protocol I was deciphering. At this point, AI was not writing any code for me.

Later, I followed my curiosity, and leaned into investigating agentic coding tools such as Claude Code, and subsequently MCP workflows both in personal and professional projects at scale. Exploring this path has opened my eyes to the possibilities of agentic workflows.

When the tools are helping you solve problems in hours or minutes that previously took days, the results are hard to ignore.

🧠 A Pragmatic Mindset

Reflecting on my own journey with AI, I found the following principles useful to think about, which could help guide you on your own journey.

Be Curious

A great engineer is a curious engineer. Therefore, try not to dismiss things on principle. The most effective way to find a signal in the noise is to try things out and learn for yourself. It’s unreasonable to give an AI a poor prompt, get mediocre results so that you can go “See, I told you it wouldn’t work!”.

Take the time to invest in your understanding to evaluate things objectively. If you come to the conclusion that it’s not for you, or it’s not a good fit for your team, that is a perfectly acceptable outcome - but do so with an open mind.

Challenge Things

Just as a good engineer challenges their stakeholders, product owners and fellow engineers (with the intention of finding the best solution, or solving the right problems), so too you should challenge the output of any AI tool: do not take things at face value, do not believe everything it tells you. Apply the intuition that you already have.

But it doesn’t stop there: challenge also the opinions of others on the subject, especially those who express polarized opinions. The reality lies somewhere in between.

Ownership is Key

Whether you agree or disagree, we may see a shift to a world where AI writes some or even all of our code, but it does not change the fact that a good engineer should take ownership and accountability for the work they produce. AI can be an effective amplifier, but it will amplify both good and bad signals.

“AI slop” is often given as an example of reasons not to use AI. A more balanced take here is that if you are witnessing this, there is likely an underlying culture problem within the team, not a tooling problem: good engineers take full ownership and accountability of the work they produce, and AI tooling should not be used as a conduit for laziness.

Truly Understand

Building on the previous point, AI can be used to shortcut parts of the development workflow, but it should not come at the cost of building genuine engineering intuition. You must still take the time to understand why a solution works, or risk becoming overdependent on tooling. Only by doing this, can you also take full ownership of the output.

Results Speak For Themselves

Ultimately, believe what you see and not necessarily what you hear: try new tools and techniques, be objective about evaluating the outcome. Be both open-minded and skeptical and make your own judgement.

💭 Closing Thoughts

Ultimately, you don’t have to love AI, but you do have to engage with it honestly to determine for yourself. A common pushback I’ve encountered is along the lines of “I like writing code, and I take pride in it”. Totally fair: but (in a work context), remember that the engineer’s goal is to achieve outcomes and not just to write code.

From my perspective, I believe that AI is an incredibly useful tool, and I’m cautiously optimistic that the way in which engineers and teams will write code is changing (and quickly too).

However, and perhaps most important, it is a tool which amplifies the engineer you already are: the gap between poor engineers and great engineers will become larger, as the impact of mistakes and successes is amplified. Stick to the fundamentals of proven engineering culture, pragmatism and common sense to find the signal within the noise.

Disclaimer: I used AI as an assistant in writing this post. Specifically, for the tasks of critiquing the article and suggesting weaknesses that could be improved, in addition to refining the outline. However, all words and thoughts are written by me.