DEV Community: Rash Edmund

I Fumbled an Interview Not because I lack Technical Skills but an Arcade Development workflow

Rash Edmund — Thu, 10 Sep 2026 04:31:08 +0000

I just fumbled a casual interview with an organization a few hours ago.

It exposed a brutal truth:
Being technically competent is no longer enough by itself.
AI has changed the "developer skillsets". It's becoming less about how fast you can write code or how much syntax you can recall and more about how well you can:

Understand the problem
- Define clear requirements
- Architect the solution
- Use AI agents to implement it
- Review and validate the output

I was unable to impress my interviewer bcs I hadn't gone a step further by having a concrete agentic workflow to show them. A developmet workflow with AI so deep at it's core that most the work is automated and executed by agents.

I was unable to show them proper usage of agent skills, not the generic ones that come pre-written and budled as part of the cofigs of your AI IDEs, but mine, customized to my own specific needs.

I tried covering this up by talking about my private agent-resources github repo that has md files explaining how I build my nextjs apps, how I setup my services and repositories as factory functions with zod schemas and mappers to normalize db and input data and that my cursor has access to this github repository and uses a reference for my projects...

But that wasn't enough.
I believe I gave them the impression that I care abit too much about syntax and that smells of "Arcade programming which implies Slow delivery" in this AI era.

You see the pose in the cover photo above ? that's exactly how I sat down thinking about this.

That's the part I'm now paying more attention to.

I wrote a full breakdown on my blog. Link in the comments.

The Unbuffered Channels In Go Lesson I Think Has Finally Clicked for Me 🤷🏽‍♂️

Rash Edmund — Sat, 01 Aug 2026 15:45:46 +0000

While struggling to understand channels in go, I would try out many things in my sandbox repository.

I encountered deadlock errors and stuff about go routes being asleep.

I came to understand that the order of execution played a role and that with unbuffered channels you need a sender and a receiver ready at the same time (kind of).

I wrote a short article on my blog site about the experience

The Unbuffered Channels In Go Lesson I Think Has Finally Clicked for Me 🤷🏽‍♂️

The Market Isn't Just Competitive Anymore

Rash Edmund — Sat, 27 Jun 2026 13:06:17 +0000

There was a time when becoming a better developer mostly meant writing better code.

Today, that's no longer enough.

The market has become so competitive that developers are expected to wear multiple hats. You're not just an engineer anymore. You're expected to build a personal brand, create content, network with other professionals, contribute to open source, maintain an impressive portfolio, and somehow still keep up with the pace of technology.

Ironically, many of these skills have little to do with writing software itself.

Companies still hire engineers to solve technical problems, but getting noticed often depends on everything surrounding your technical ability. A well-written article, an active X profile, a conference talk, or an open-source contribution can sometimes create opportunities that another certification simply won't.

That doesn't mean technical skills have become less important. If anything, the technical bar is higher than ever. The difference is that being a great engineer is no longer enough to guarantee visibility.

The developers who stand out today often combine strong engineering skills with communication, consistency, and community involvement.

It's a difficult reality, especially for people who simply want to build software. But understanding the market is part of succeeding in it.

In many ways, software engineering has evolved beyond code. You're not only building products anymore, you’re also building trust, credibility, and a reputation that travels ahead of your résumé.

AI Is Exposing Technical Debt We Learned to Ignore

Rash Edmund — Fri, 19 Jun 2026 19:14:53 +0000

One thing I've noticed while working with AI tools is that they struggle with many of the same things junior engineers struggle with.

Not algorithms, and syntax, nor frameworks.

They struggle with ambiguity.

Give an AI vague requirements and you'll get vague results.

Point it at a codebase with inconsistent abstractions and it will make incorrect assumptions.

Ask it to work with undocumented business rules and it will confidently fill the gaps with guesses.

For years, teams survived these problems because people carried the missing context in their heads. New engineers asked questions. Senior engineers explained the history behind certain decisions. Knowledge spread through conversations.

AI doesn't have access to those conversations.

It only sees what's actually written down.

That's why, looking at some of the basic requirements for working with ai tools, I think AI is doing something unexpected: it's making software quality more visible.

A clean architecture isn't just easier for developers to navigate. It's easier for AI tools to understand.

Clear requirements aren't just good project management. They're becoming a prerequisite for effective AI collaboration.

The interesting lesson isn't that AI is imperfect.

It's that many of the things confusing AI were already confusing humans.

We just got used to working around them.

Why Most AI Features Fail After the Demo

Rash Edmund — Fri, 19 Jun 2026 07:01:48 +0000

Every week, a new product announces an AI feature.

A chatbot.
An agent.
A smart assistant.
An AI-powered search experience.

The demo looks impressive.

The launch gets attention.

Then six months later, nobody is using it.

Why?

Because building an AI feature and building an AI product are two completely different things.

The Demo Trap
Most AI features are designed for first impressions.

Ask a question.

Get a surprisingly good answer.

Share it on social media.

The problem is that real users don't interact with software the way demo videos do.

Real users are inconsistent.

They provide incomplete information.

They ask vague questions.

They expect reliability after the novelty wears off.

The gap between a successful demo and a useful product is much larger than many teams expect.

Intelligence Is Not the Product
A common mistake is treating the model itself as the product.

But users rarely care about the model.

They care about outcomes.

Nobody buys an email client because it uses a specific database.

Nobody chooses a ride-sharing app because of its backend architecture.

Likewise, most users do not care whether your application uses Gemini, GPT, Claude, or another model.

They care whether the system helps them accomplish a task.

The intelligence is infrastructure.

The product is the experience built around it.

Context Matters More Than Capability
A general-purpose model knows a lot.

A product needs to know the right things.

Consider two assistants:

The first can answer thousands of questions about almost anything.

The second only answers questions about your company, products, documentation, and support processes.

The second assistant is often more valuable despite being more limited.

Why?

Because it has context.

Users often prefer a focused assistant that consistently solves their problem over a powerful assistant that occasionally wanders into irrelevant territory.

Observability Is Underrated
One lesson many teams learn late is that AI systems need observability.

Traditional software gives predictable outputs.

AI systems do not.

If users are interacting with an assistant, you need visibility into:

What people are asking

Where responses fail

Which prompts create confusion

Which workflows are being abandoned

Without that feedback loop, improving the system becomes guesswork.

Guardrails Are Features
Many developers view restrictions as limitations.

In reality, constraints often improve the user experience.

An assistant that tries to answer everything usually performs worse than one with a clearly defined scope.

Users trust systems that behave predictably.

Sometimes the best response is not generating an answer.

Sometimes the best response is saying:

"I can't help with that."

The Future Belongs to Useful AI
The next wave of successful AI products will probably not be the most intelligent.

They will be the most useful.

They will have:

Clear boundaries

Strong context

Reliable behavior

Good observability

Thoughtful user experiences

The model will still matter.

But increasingly, the competitive advantage will come from product design rather than model selection.

The companies that understand this distinction will build products people continue using long after the demo ends.

The Most Dangerous Code in Your App Might Be a Fresh Dependency

Rash Edmund — Tue, 12 May 2026 11:46:48 +0000

The recent TanStack supply-chain compromise is a reminder that modern attacks are increasingly targeting the software delivery pipeline itself, not necessarily the frameworks or runtime code we use.

Their detailed post gives better insight into the impact, timeline, root cause, detection, and lessons learned: Read here.

A few practical mitigations are starting to feel less “optional” now:

minimum-release-age delays before installing newly published packages
stricter CI/publishing permissions
explicit package versions instead of broad ranges
verified publishing and provenance tooling

Yes, exact versions mean you manually handle patches and minor upgrades more often.

And minimum-release-age delays are not perfect either; they can also slow down urgent security patches.

But together, these measures help reduce the chance that a compromised package published minutes ago lands directly in production.

The ecosystem is entering an era where CI pipelines, package registries, publishing permissions, and dependency trust all need to be treated as part of application security.

If AI Writes the Code, Your Specs Become the Product

Rash Edmund — Wed, 06 May 2026 18:40:15 +0000

The question is no longer whether developers can write clean code.

The real question is: can we write specifications that machines can’t misunderstand?

As AI tools become part of everyday development workflows, the bottleneck is shifting. Code is no longer the hardest artifact to produce, rather clear, unambiguous intent is. When working with AI, vague requirements really don’t just slow things down, they tend to multiply errors at scale.

A human developer might pause to ask clarifying questions, An AI model won’t. It will confidently execute exactly what was written/promted; no more, no less.

Clean specifications are now a core engineering skill. They require:

Precision over assumption
Explicit constraints over implied logic
Structured thinking over informal descriptions

In many ways, writing specs for AI is closer to designing a contract than giving instructions. This is so beacause every ambiguity or missed edge case is a potential bug and failure.

The developers who thrive in this new environment won’t just be great coders, they’ll be "exceptional communicators of intent".
Because in an AI-assisted world, clarity is everything.