DEV Community: Dewald Els

The Unstoppable Current: Why Change Is the Only Constant You Can Count On

Dewald Els — Fri, 17 Apr 2026 05:42:48 +0000

Riding the wave of technological transformation — before it rides you.

Change doesn't ask for permission. It doesn't wait for you to finish reading the manual on the last thing that changed. It arrives, reshapes everything around you, and moves on — leaving you holding documentation for something that's already obsolete.

We are living through one of the most compressed periods of transformation in human history. And the uncomfortable truth? We don't have time to fully understand it.

Things Change. Always. That's the Deal.

Change is not new. Seasons change. Empires rise and fall. Languages evolve, die, and get replaced. The wheel, the printing press, electricity, the internet — each one arrived and rewired how humanity functioned.

But here's what is new: the speed.

Technology is now changing faster than our collective ability to understand it. We barely grasp the possibilities, limitations, and risks of one wave before the next one is already breaking. We don't fully understand large language models yet — and multi-agent systems are already being deployed in production. We haven't resolved the ethical implications of deepfakes — and real-time AI video generation is already here.

There is no finish line where we finally "get it." The course keeps changing mid-race.

We Don't Love Change. We Love New.

Here's a nuance worth sitting with: humans don't actually love change. Change is uncomfortable, disruptive, even threatening. What we love is novelty.

New gadget. New feature. New model. New release. That dopamine hit when something feels fresh and exciting — that's not logic. That's biology.

Neuroscience is clear on this. When the brain encounters something potentially rewarding, neurons in the ventral tegmental area (VTA) activate and release dopamine — the brain's primary "reward" neurotransmitter. That dopamine burst travels to the nucleus accumbens and sends a signal to the prefrontal cortex, the part of the brain responsible for decision-making and planning. (Brain Reward System, Simply Psychology)

In other words, the anticipation of something new triggers a reward response before your rational mind has had a chance to evaluate whether the new thing is actually good, safe, or worth it.

When this system is in full swing, executive brain regions like the prefrontal cortex can become suppressed, while deeper reward-tracking areas like the nucleus accumbens are overemphasised — meaning we can lose the ability to properly weigh consequences because the dopamine signal overrides more rational assessments. (Addictive Behaviors Restructure Your Brain's Dopamine System, Medium / AI_ML)

This is not a character flaw. It is a feature of being human. But it is something we should be aware of — especially when the thing triggering our dopamine is a new AI tool promising to change everything.

AI and the Long Arc of How We Record Thought

To understand where we are with AI, it helps to zoom all the way out.

Human beings have always searched for better ways to externalise thought — to get ideas out of our heads and into the world.

Around 3400 BCE, the Sumerians developed cuneiform — pressing a reed stylus into wet clay tablets to create wedge-shaped marks. It was slow, physical, and permanent.
Ink and papyrus gave way to faster, lighter writing. Then came the codex — the bound book.
The printing press in the 1440s didn't just speed things up. It democratised the creation and distribution of knowledge in a way that reshuffled power across entire civilisations.
Typewriters mechanised the act of writing. Computers digitised it. The keyboard became the universal interface for thought.

And now? We are at another inflection point.

We still use the keyboard — but increasingly, we are describing what we want written rather than writing it ourselves. The act of producing text is being abstracted away. Instead of pressing a key to produce a character, we are prompting a model to produce a document, a function, an argument, a strategy.

The analogy isn't perfect — a Sumerian scribe pressing clay had intent, craft, and judgment baked into every mark. We should be careful not to lose that judgment as we hand more of the execution to machines. But the direction of travel is clear: each era found a way to make the recording of thought faster, more scalable, and more accessible. AI is the latest step on that path — and arguably the most discontinuous one yet.

AI Is Not Just a Tool. It's a Driver.

Previous technologies augmented human effort. AI is beginning to substitute for it — at least in certain domains. Code gets written. Emails get drafted. Analyses get generated. Decisions get informed.

This creates a genuinely new set of questions:

What do we lose?
Craft. Deep comprehension. The slow-burn understanding that comes from struggling with a problem yourself. The junior developer who never has to debug anything may become the senior developer who doesn't understand why anything works.

What do we gain?
Speed. Accessibility. The ability for one person to do what previously required a team. Reduced barriers to entry. More time to focus on higher-order thinking — if we choose to use it that way.

Who decides the return on investment?
This is the question nobody is asking loudly enough. When AI writes your code, who owns the quality bar? When an agent ships a feature, who is accountable for what it does in production? The efficiency gains are real — but they don't distribute evenly, and the risks don't either. The developer, the team, the organisation, and ultimately the user all have skin in the game. The ROI calculation isn't just financial. It's about skill atrophy, dependency risk, and what happens when the model gets it confidently wrong.

Practical: Embracing the Change Without Losing the Plot

Understanding the shift is one thing. Operating effectively inside it is another. Here's how to engage with AI-driven development in a grounded, productive way.

Using Agents

An AI agent is a system that can take actions autonomously to complete a goal — not just answer a question, but execute a sequence of steps: reading files, writing code, running tests, calling APIs, and iterating based on results.

Where a standard chat interaction is a single exchange, an agent is a loop. You give it a goal; it works toward that goal across multiple steps, using tools along the way.

Agents are powerful precisely because of that autonomy — and risky for exactly the same reason. A well-scoped agent with the right tools and guardrails is enormously productive. A poorly scoped one can make confident, cascading mistakes.

Tools: Claude Code, Codex, OpenCode and Others

The agentic coding landscape is growing fast. A few of the key players:

Claude Code (Anthropic) — A command-line agentic coding tool that operates in your terminal, reads your codebase, writes and edits files, runs tests, and interacts with git. It is designed to work on real engineering tasks with full project context.
Codex (OpenAI) — OpenAI's coding-focused model, now powering a cloud-based agent that can work on tasks in an isolated sandbox environment.
OpenCode — An open-source, terminal-based AI coding assistant that supports multiple LLM backends. Lightweight, flexible, and designed for developers who want control over their tooling.

These are not autocomplete tools. They are systems that can reason about your codebase and act on it.

Understanding these concepts is one thing — but the best way to internalise them is to actually get your hands dirty. The tools available today are more accessible than they've ever been, and you don't need to architect a full multi-agent system to start benefiting from agentic workflows. The smartest move is to start small: pick one tool, get it running in a real project, and observe how it reasons. Build your intuition before you build your pipeline. With that in mind, let's walk through setting up OpenCode — one of the most developer-friendly entry points into agentic coding. It's open-source, runs in your terminal, supports multiple LLM backends, and gets you from zero to agentic in under five minutes.

Let's Build: Your First Agentic Setup

Prerequisites

Node.js 18 or higher
An API key for at least one supported LLM provider (Anthropic, OpenAI, etc.)

Step 1: Install OpenCode

npm install -g opencode-ai

Step 2: Configure your API key

OpenCode uses environment variables for authentication. Set your preferred provider:

# For Anthropic (Claude)
export ANTHROPIC_API_KEY=your_api_key_here

# For OpenAI
export OPENAI_API_KEY=your_api_key_here

You can add these to your .bashrc, .zshrc, or equivalent shell config to persist them.

Step 3: Launch OpenCode in your project

Navigate to your project directory and run:

cd your-project
opencode

This opens the interactive TUI (terminal user interface) inside your project context.

Step 4: Configure your model (optional)

OpenCode supports a config file (opencode.json or via the TUI settings) where you can specify:

Your preferred model (e.g., claude-sonnet-4-5, gpt-4o)
Context window behaviour
Tool permissions (file reads, shell execution, etc.)

Step 5: Give it a task

Inside the TUI, describe what you want done in plain language:

Add input validation to the user registration form and write tests for it.

OpenCode will read your codebase, propose a plan, and — with your approval — execute it.

Tips for working with OpenCode effectively:

Be specific about scope. "Fix the authentication module" is worse than "Fix the JWT expiry bug in auth/token.js."
Review every diff before approving. Agents can be confidently wrong.
Use it iteratively. Small, focused tasks outperform large, vague ones.
Keep your repo clean before starting. Agents work better with clear git history.

Something Else Worth Looking Into: Orchestrators

Once you've spent some time with a single agentic tool and you're comfortable with how agents reason and act, there's a natural next question: what happens when one agent isn't enough?

That's where orchestrators come in — and it's a rabbit hole worth going down when you're ready.

An orchestrator is the layer that coordinates multiple agents, tools, or models to accomplish a complex task. A single agent is a specialist. An orchestrator is the manager — breaking large goals into subtasks, delegating to the right agents, handling failures, and synthesising everything into a result.

It's a step up in complexity, but also a step up in what becomes possible. Frameworks like LangChain, LangGraph, CrewAI, and AutoGen are popular starting points. Anthropic's documentation also covers orchestration patterns using Claude as a directing model over a set of specialised sub-agents.

The key principle to carry with you: the orchestrator doesn't do the work. It coordinates who does.

It's not something you need on day one. But once single-agent workflows start feeling like a limitation, you'll know it's time.

Conclusion

Change is not coming. Change is already here, already reshaping what it means to write software, create content, and solve problems. The question is never whether to adapt — it's how to adapt with intention.

The developers and teams that will thrive are not the ones who adopt every new tool reflexively — chasing that dopamine hit of novelty — nor the ones who resist change out of comfort. They are the ones who engage critically: understanding what they gain, naming what they risk losing, asking hard questions about accountability, and then building deliberately with the best tools available.

The arc from clay tablet to keyboard to AI agent is long. We are privileged to be standing at one of its most remarkable bends.

Don't fear the current. Learn to navigate it. The future belongs to those who stay curious, stay critical, and keep building.

#AIChange #FutureOfCoding #AgenticAI #TechEvolution #DeveloperTools

Image: Photo by Ryoji Iwata on Unsplash

Vibe Coding vs. Guided AI Coding: Why Your Dog's Treat App Depends on Who's Typing

Dewald Els — Thu, 05 Mar 2026 19:21:33 +0000

There's a moment every new "vibe coder" eventually hits. You've seen the tweets. Someone built a SaaS in a weekend with nothing but ChatGPT and a dream. So you open up Claude Code, crack your knuckles, and type something like:

"make me an app"

And the AI, bless its heart, tries. It makes something. Maybe it even looks kind of impressive at first glance. But three prompts later you're staring at broken code you don't understand, asking the AI to fix the thing it just built, which breaks two other things, and suddenly your weekend SaaS is a weekend crisis.

This isn't a hit piece on beginners. Everyone starts somewhere. This is an honest look at why AI coding tools — Claude Code, OpenCode, Codex, Cursor, take your pick — are not a great equalizer so much as a multiplier. And multiplying zero still gives you zero.

Let's explore this with the most important app idea of our generation: an on-demand treat ordering app for dogs.

The Vibe Coder Enters the Chat

Our protagonist, let's call him Dave, has never written a line of code. Dave has a dog named Gerald. Gerald wants treats. Dave has seen the demos. Dave is ready.

Dave opens Claude Code and types his first prompt:

make an app where dogs can order treats

The AI now has to make approximately forty decisions Dave hasn't thought about:

Is this a web app? Mobile? Desktop?
What's the backend? Is there even a backend?
How do dogs "order"? Is there a UI? Who actually uses it — the dog or the owner?
What kind of treats? Is there a catalog?
Is there payment? Delivery? Just a wishlist?
What language? What framework? What database?

The AI isn't psychic. It picks React because that's a safe guess. It invents a treat catalog. It adds a shopping cart. It skips authentication because Dave didn't mention users. It skips a database because Dave didn't mention persistence. It generates about 200 lines of code that renders nicely in a browser and does absolutely nothing when you press "Order."

Dave sees the UI and thinks it's almost done. Dave types:

now make it actually work

The Assumption Avalanche

This is where vibe coding really starts to wobble. Every vague prompt forces the AI to assume. Every assumption it makes is one more thing Dave doesn't know about, doesn't control, and will eventually need to fix without knowing how.

Here's a small gallery of classic vibe-coding prompts and what the AI silently decides on your behalf:

Prompt: add a login

AI assumes: JWT tokens, localStorage, no refresh token strategy, no rate limiting, passwords hashed with bcrypt but stored with no salting config documented, email as username.

Prompt: connect it to a database

AI assumes: SQLite locally (fine for now, nightmare later), no migrations, no indexes, a schema it invented that may not match what you actually need.

Prompt: make it look better

AI assumes: You want Tailwind, a color palette it picked, a layout that overrides your existing CSS, and three new dependencies added to your project.

Prompt: add payments

AI assumes: Stripe, test mode only, no webhook handling, no error states, no refund logic, and a hardcoded API key it politely warns you to move to an env file — which Dave does not know how to do.

None of these are wrong decisions necessarily. But they're all decisions. Dozens of them. Silently made. And when something breaks — and it will break — Dave has no map of the territory.

The AI built a house. Dave doesn't know where the load-bearing walls are.

Enter the Expert

Now let's watch a senior developer — let's call her Priya — tackle the same dog treat app. Priya has ten years of experience. She knows what she wants before she types a word. Her first prompt looks a little different:

I'm building a Next.js 14 app using the App Router. I want to scaffold a 
treat ordering feature for a pet e-commerce platform. 

For now I need:
- A /treats route with a static product listing page (server component)
- Each treat card should have: name, image, price, and an "Add to Cart" button
- Cart state managed client-side with Zustand — no persistence yet
- TypeScript throughout, strict mode on
- Tailwind for styling, keep it minimal for now

Don't add auth, payments, or a database yet. I'll handle those in later 
sessions. Start with the file structure and the Zustand store, then we'll 
build the components.

Look at what Priya has done here. She has:

Named the framework and version
Named the specific routing paradigm within that framework
Drawn a hard boundary around scope (no auth, no payments, no DB — yet)
Named her state management library
Specified the type system
Asked for a specific starting point, not the whole thing at once

The AI doesn't have to guess at a single architectural decision. It executes. The output is clean, idiomatic, and slotted perfectly into a larger system Priya already has in her head.

Here's roughly what that Zustand store looks like when the AI generates it to Priya's spec:

// store/cartStore.ts
import { create } from 'zustand'

interface Treat {
  id: string
  name: string
  price: number
  imageUrl: string
}

interface CartItem extends Treat {
  quantity: number
}

interface CartStore {
  items: CartItem[]
  addItem: (treat: Treat) => void
  removeItem: (id: string) => void
  clearCart: () => void
  total: () => number
}

export const useCartStore = create<CartStore>((set, get) => ({
  items: [],
  addItem: (treat) => {
    const existing = get().items.find(i => i.id === treat.id)
    if (existing) {
      set(state => ({
        items: state.items.map(i =>
          i.id === treat.id ? { ...i, quantity: i.quantity + 1 } : i
        )
      }))
    } else {
      set(state => ({ items: [...state.items, { ...treat, quantity: 1 }] }))
    }
  },
  removeItem: (id) =>
    set(state => ({ items: state.items.filter(i => i.id !== id) })),
  clearCart: () => set({ items: [] }),
  total: () =>
    get().items.reduce((sum, item) => sum + item.price * item.quantity, 0)
}))

This is production-quality code. No hand-waving. No placeholders. It handles the edge case of adding a duplicate item. It has a derived total() function. It's typed. Dave's version had a useState([]) and a button that logged "add to cart" to the console.

The Same Tool, A Different Universe

Both Dave and Priya used an AI coding assistant. Both asked it to build a treat ordering app. The outputs are not in the same category. Not even close.

This is the part the viral "built a SaaS in a weekend" tweets leave out. The person doing it has usually been coding for a decade. They're not discovering what an API is — they're offloading the tedious parts of work they already know how to do. The AI is a force multiplier for their existing knowledge.

When Priya hits a bug, she can read the code the AI wrote and understand it. She can spot where the AI made a trade-off she disagrees with. She knows when to push back, when to accept, and when to throw the output away entirely and ask again with tighter constraints.

Dave cannot do any of that. Dave is entirely at the mercy of what the AI produced. When it breaks, he can only prompt his way deeper into the maze.

This Doesn't Mean Beginners Should Give Up

To be fair: there are valid use cases for vibe coding even without experience. Automating a personal spreadsheet. Building a simple form that emails you results. Making a quick prototype to show a client. These are achievable.

Gerald the dog might very well get a functional treat ordering page eventually. With enough iteration, enough patience, and a tolerant AI, Dave could get something working.

But "working" and "good" are miles apart. And "good" and "maintainable" are miles further. Anyone can drive a car through a field. That doesn't make them a racing driver.

The ceiling for what an inexperienced prompter can build is low — not because AI is hard to use, but because building software is hard to think about. The AI is fluent in code. The bottleneck is always the ideas, the architecture, the constraints, and the judgment being fed into it.

What Beginners Can Actually Do

If you're Dave and you want to get better results, here are a few things that help:

Be specific about what you don't want. "Don't add authentication yet" is as powerful as "add a login page." Scope control is everything.

Ask the AI to explain its decisions. "Before you write any code, tell me what approach you're planning and why." This forces the AI to surface assumptions before they're baked into 300 lines of code.

Work in tiny slices. Don't ask for the whole app. Ask for one component. Get it working. Then ask for the next one. Gerald's treat catalog before Gerald's checkout flow.

Learn just enough to read the output. You don't need to be a developer to recognize that a function with no error handling is going to cause problems. A little literacy goes a long way.

In Conclusion

AI coding tools are extraordinary. They've genuinely changed what a single developer can build. But they haven't changed what it takes to build something well. They've made the execution cheaper, not the thinking.

In the hands of an expert, Claude Code or OpenCode or Codex is like giving a master chef a robot sous-chef that never sleeps. In the hands of someone who's never cooked, it's a kitchen full of sharp knives and high heat.

Gerald deserves better than a broken treat app with no database and a hardcoded Stripe test key.

And frankly, so does Dave.

The gap between vibe coding and guided AI coding isn't about intelligence — it's about knowledge. The good news is that knowledge is learnable. The even better news is that while you're learning, the AI is a pretty great teacher too. Just maybe don't ask it to build your production app on day one.

Photo by Tamas Pap on Unsplash