DEV Community: Blaise “Mawulolo” Akpalu

When Did Being a Beginner Start Feeling Like Falling Behind?

Blaise “Mawulolo” Akpalu — Wed, 21 Oct 2026 16:34:28 +0000

On learning, comparison, and remembering that growth was never meant to be a race.

Lately, I've been learning new technologies, particularly AWS and blockchain development. It's exciting stepping into unfamiliar territory again, but I've noticed something interesting.

You start learning. You're making progress. Things are slowly beginning to make sense. Then you open LinkedIn. Someone just became 6x AWS Certified.
Someone else seems to have mastered an entire technology stack in a few months. Another person is sharing a roadmap explaining how to become an expert in something you've barely started learning.

And suddenly, what felt like progress five minutes ago starts to feel like you're falling behind. You're only just getting started, yet somehow you already feel late.

When Learning Starts Feeling Like a Race

We live in an incredible time to be curious. Almost anything we want to learn is available within a few clicks. We have courses, documentation, tutorials, roadmaps, communities, and now AI tools that can explain difficult concepts almost instantly. That's a good thing.

But I've been thinking about how having access to so much information can also create an unexpected pressure: the feeling that because the information is available, we should somehow become competent almost immediately. And social media amplifies that feeling.

We constantly see people's certifications, promotions, successful projects, businesses, transformations, and milestones.

What we don't always see are the months or years of confusion, mistakes, failed attempts, practice, and persistence that came before them.
We end up comparing our beginning with someone else's years of experience.

I Remember What It Took to Get Here
My journey into software development started from a graphic design background. I remember spending countless hours trying to understand concepts that feel much more natural to me today.

Reading documentation.
Following tutorials.
Building things.
Breaking things.

Debugging things I had no idea how I'd broken in the first place.
And there were those problems you would spend hours trying to solve.
Eventually, you'd get tired and think: I'll deal with this tomorrow.
Then you'd go to bed and suddenly... 💡.
The solution appears in your head when you're nowhere near the computer.
You come back, try it, and somehow it works.

Looking back, those moments weren't interruptions to learning.
They were the learning. The frustration, experimentation, mistakes, and small breakthroughs gradually shaped how I approached problems.

They taught me patience and persistence, but they also gave me something important: the confidence that just because I don't understand something today doesn't mean I won't understand it eventually.
_

> It's Okay to Be a Beginner Again

Years later, I'm now finding myself in that position again. I have experience in software development, but AWS and blockchain introduce concepts I'm still learning. And that's okay. Being experienced in one area doesn't mean you stop being a beginner in another. In fact, I think there's something valuable about deliberately putting yourself in that position again.

You get to ask questions. You get confused. You experiment. You get things wrong. And eventually, something that once seemed complicated begins to make sense. That's a pretty rewarding experience.

AI Makes Learning Faster, but the Journey Still Matters

I love what AI has made possible. We can get explanations faster, explore ideas more easily, and overcome problems that might previously have taken considerably longer to research.

I don't think we should struggle unnecessarily just to prove that we've learned something. But I also don't want speed to make us forget something important: Having access to an answer isn't always the same as understanding it. There's still value in wrestling with an idea, experimenting with it, applying it, making mistakes, and eventually reaching that moment where you genuinely understand why something works.

The tools may change. Learning will become faster. But that feeling of finally getting it is still worth something. Maybe We're Not Behind There's always going to be someone further along. Someone with more certifications. Someone with more experience. Someone who started earlier. Someone progressing faster. But their progress doesn't make yours insignificant. Sometimes progress is earning a major certification. Sometimes it's completing your first project.

And sometimes it's simply understanding something today that completely confused you yesterday. All of it counts. Maybe being a beginner isn't something we need to rush through. Maybe there's value in not knowing yet.
In being curious. In making mistakes. In allowing ourselves enough time to grow. Because the goal isn't only to become good at something. It's also to appreciate who we're becoming while learning it. Maybe we're not falling behind. Maybe we're simply learning.

Have you ever caught yourself feeling behind while learning something new, even though you were actually making progress?

Giving AI Coding Agents Context Without Giving Them Your Entire Codebase

Blaise “Mawulolo” Akpalu — Mon, 28 Sep 2026 04:27:14 +0000

AI coding agents are becoming remarkably good at working inside real codebases.

Give an agent enough information and it can understand your components, follow existing patterns, trace data flow, create new features, refactor code, and even reason about architectural decisions.

But there is a problem:

«More context doesn't always mean better results.»

Giving an agent access to your entire codebase may seem like the best way to help it understand your project.

In practice, unnecessary files can introduce noise, increase token usage, expose implementation details that aren't relevant to the task, and make it harder to identify what actually matters.

I've been thinking about this as I work more with AI coding agents, and I believe the better approach is to treat context as something you intentionally design.

The Context Problem

When working with an AI coding agent, it's tempting to give it everything:

The entire repository
Every configuration file
All database schemas
Every API endpoint
Environment variables
Authentication logic
Old implementations
Unrelated features
Internal business logic

The thinking is simple:

«"If the agent knows everything, it can make better decisions."»

But software engineers don't usually work this way.

When you join an unfamiliar project, you aren't typically handed the entire repository and told:

«"Figure it out."»

You're given a task, some background, the relevant files, and the conventions you need to understand the problem.

AI agents can benefit from the same approach.

Start With the Task

Before giving an agent access to a collection of files, define what you're actually asking it to do.

For example, suppose you want to add a contributor submission feature.

The agent probably doesn't need:

Your entire admin dashboard
Your payment system
Your analytics implementation
Every unrelated database table
Your deployment configuration

It may need:

Task
│
├── Contributor submission requirements
├── Existing article model
├── Submission API/server action
├── Authentication/session interface
├── Relevant UI components
└── Validation conventions

That's enough to establish a useful working boundary without making the entire repository part of the problem.

Separate Interfaces From Implementations

One useful way to reduce unnecessary context is to distinguish between:

What a system does
and
How it does it.

For example, an agent may need to know that your application has an authentication system:

const session = await getSession();

if (!session?.user) {
  return unauthorized();
}

It may not need to understand the entire implementation of:

Session storage
OAuth providers
Cookie configuration
Database adapters
Token handling
Internal authentication utilities

The interface tells the agent what it needs to use.

The implementation explains how everything works underneath.

Unless the task requires changing authentication, exposing all of those details may add complexity without improving the solution.

Think in Boundaries

A useful mental model is to treat your application as a collection of boundaries.

            ┌─────────────────────┐
             │       UI Layer      │
             └──────────┬──────────┘
                        │
             ┌──────────▼──────────┐
             │   Feature Logic     │
             └──────────┬──────────┘
                        │
             ┌──────────▼──────────┐
             │   Data / API Layer  │
             └──────────┬──────────┘
                        │
             ┌──────────▼──────────┐
             │    Infrastructure   │
             └─────────────────────┘

If you're asking an agent to modify a UI component, it may only need the UI layer and the relevant interfaces from the layers below it.

If you're changing database behaviour, you'll probably need more of the data layer.

The important idea is:

«The agent's working boundary can be smaller than the application's boundary.»

Runtime Boundaries vs Agent Boundaries

Your application may legitimately have access to:

Authentication
Database
Payments
Users
Analytics
Admin
Storage
Email

But an agent working on a profile component might only need:

Profile component
User type
Profile API contract
Validation schema
Relevant UI conventions

The application needs the complete system to operate.

The agent only needs enough of the system to perform the task.

This distinction becomes increasingly important as agents gain more autonomy.

Create Sanitized Blueprints

Another approach is to create small architectural blueprints that explain how parts of your application work without exposing every implementation detail.

For example:

Feature: Contributor Posts

UI
└── ContributorPostForm

Server
├── submitContributorPost()
└── validateContributorPost()

Data
├── contributor_posts
└── users

Authentication
└── getCurrentUser()

Flow

Contributor
   ↓
Post Form
   ↓
Validation
   ↓
Server Action
   ↓
Database
   ↓
Admin Notification

An agent can understand the architecture from this without reading every file involved in the system.

You can then provide the actual implementation files when they're required.

There's also a useful side effect:

«The blueprint becomes documentation for humans too.»

Context Can Become a Security Boundary

This isn't only about producing better code.

It can also become part of your security model.

An AI coding agent that can access everything potentially has access to:

Sensitive business logic
Internal APIs
Customer information
Database structures
Private documentation
Infrastructure configuration
Secrets or credentials if your environment is poorly configured

Even when secrets are properly protected, unnecessarily exposing internal implementation details increases the amount of information an agent can access and reason about.

A more deliberate architecture could look like this:

             AI Agent
                │
                ▼
       ┌─────────────────┐
       │ Allowed Context │
       └────────┬────────┘
                │
      ┌─────────▼─────────┐
      │ Contracts / APIs  │
      │ Schemas / Types   │
      │ Relevant Files    │
      └─────────┬─────────┘
                │
                ▼
          Application

This doesn't mean an agent should never access deeper parts of the system.

It means access can be intentional and scoped to the work being performed.

A Practical Agent Workflow

I like thinking about an AI coding task as a gradual process rather than a single prompt.

Define task
     ↓
Identify required files and contracts
     ↓
Provide relevant context
     ↓
Ask agent to propose an approach
     ↓
Review the approach
     ↓
Expand context if necessary
     ↓
Implement
     ↓
Run tests / security checks
     ↓
Review changes
     ↓
Merge

The important part is:

«Expand context if necessary.»

If the agent discovers that it needs information about another part of the system, provide it.

This makes the interaction more deliberate than simply giving the agent unrestricted access from the beginning.

This Changes How We Think About AI Coding

AI coding isn't only about writing better prompts.

It is also about designing better context boundaries.

As AI agents become more capable, developers may spend less time manually writing every line of code and more time deciding:

What the agent should know
Which abstractions should be exposed
Which implementation details should remain hidden
What constraints the agent should follow
How changes should be validated

That starts to look less like traditional prompting and more like software architecture.

The Bigger Idea

I've started thinking about AI coding agents almost like another developer joining a project.

You wouldn't give a new developer unrestricted access to every system on their first day.

You'd give them:

The task
The relevant documentation
The architectural conventions
The interfaces they need
The files related to the feature
Additional context as their understanding grows

AI agents can be approached in a similar way.

The goal isn't simply to give an agent less information.

It's to give it the right information at the right time.

«Good AI-assisted development may depend less on how much context we provide and more on how intentionally we design that context.»

A Note on Terminology

I'm using "AI coding agent" broadly to describe tools that can inspect a codebase, reason about changes, modify files, and run development tasks with varying degrees of autonomy.

The specific capabilities and context mechanisms differ between tools, but the underlying principle applies broadly:

«Give the agent the context it needs — not everything you have.»

What has your experience been with giving AI coding agents context? Do you give them broad access to your codebase, or do you deliberately scope what they can see?

The Frontend Role Is Changing — And AI Is Raising the Bar

Blaise “Mawulolo” Akpalu — Mon, 21 Sep 2026 16:05:25 +0000

I recently read a discussion about the distinction between a frontend developer and a frontend engineer, and it got me thinking about how much the role itself has changed.

When I started my web development journey years ago,coming from a graphic design background, learning frontend development was a deep journey into understanding the technologies behind the web.

I spent countless hours on W3Schools,YouTube channels like Traversy Media, The Net Ninja, and Academind, and courses from ZTM and Udemy.

I loved being able to turn ideas into beautiful, interactive interfaces that clients and users were excited about.

But the frontend landscape has expanded significantly. It is no longer just about building the interface. You now have to manage:
- Architecture: Component structure, data fetching, and API integration.
- Systems: Design systems, authentication, and deployment pipelines.
- Performance & UX: Accessibility, SEO, load speeds, and overall product experience.

Frameworks like Next.js have also blurred traditional boundaries between frontend and backend, giving frontend developers more responsibility for how an application works as a whole.

And then came AI. Tools like Claude Code, Codex, Cursor, and others can generate functional frontend code in minutes. AI can also accelerate the design and prototyping process dramatically.

So if AI can increasingly handle code generation, what becomes more valuable? Understanding what to build, why to build it, how the pieces fit together, and evaluating whether what AI produced is actually good.

I think that’s where frontend development is heading.
Knowing how to code still matters.But knowing how to think about software matters even more.