There's a quiet question spreading through the developer world:
"If AI can write code, what happens to programmers?"
Some respond with denial — believing AI is simply hype and that software development will remain unchanged.
Others respond with surrender — accepting that AI will do the work, while developers simply describe what they want, copy the output, and hope it works.
I believe both responses miss the real question.
The question isn't:
"Will AI replace programmers?"
The better question is:
"What kind of programmer will you become when AI can do more of the work?"
Because AI is not simply something happening to programmers.
It is becoming something programmers can work with.
And that changes our responsibility.
Who This Is For
This is for the beginner writing their first program and wondering whether learning to code still matters.
It is for the developer who has become faster with AI but sometimes wonders whether they are becoming weaker at thinking.
It is for the experienced engineer designing systems, reviewing code, mentoring others, and trying to understand how AI changes the craft.
It is for the self-taught developer building alone.
It is for students, professionals, freelancers, architects, creators, and anyone who wants to use AI without surrendering their ability to think.
Because this is where the conversation should begin:
AI should make you more capable—not less capable.
What We Believe
We believe AI is one of the most powerful tools ever placed in the hands of a programmer.
We also believe that powerful tools can become dangerous shortcuts when the person using them stops thinking.
We believe the value of AI isn't simply how much code it can generate.
Its value is in how effectively a developer can use it to learn, reason, build, investigate, test, review, and improve.
We believe programming fundamentals still matter.
Perhaps more than ever.
Generating code is becoming easier.
Understanding what that code should do, whether it is correct, secure, maintainable, appropriate, and worth shipping remains an engineering responsibility.
We believe copy-pasting code you don't understand is not the same as learning to program.
You may have borrowed a solution.
You haven't necessarily developed the ability to solve the problem yourself.
We believe AI shouldn't only answer our questions.
It should challenge our assumptions.
Expose weaknesses in our reasoning.
Present alternatives.
Help us investigate.
Help us learn.
Help us become better thinkers.
And we believe BY MY SELF does not mean without help.
It means with ownership.
I can use AI.
I can use documentation.
I can use books.
I can use mentors.
I can use communities.
I can use every tool available to me.
But I must still understand what I am building and take responsibility for the decisions I make.
The goal isn't to become a programmer who never uses AI.
The goal is to become a programmer who can use AI without becoming dependent on it.
The Seven Principles
These seven principles form the spine of AI & The Programmer.
Every article, lesson, project, experiment, and BY MY SELF progress update can connect to one or more of them.
1. From Code Generation to Problem Solving
AI can generate code.
But software development begins before the code.
Understand the problem.
Define the requirements.
Identify the constraints.
Break the problem down.
Consider possible solutions.
Then use AI to accelerate the work.
Don't begin with:
"What code should I write?"
Begin with:
"What problem am I actually solving?"
2. From AI as an Answer Machine to AI as a Thinking Partner
The easiest way to use AI is to ask it for answers.
The more valuable way is to use it to improve your thinking.
Ask it to explain.
Challenge your assumptions.
Review your design.
Find weaknesses.
Generate alternatives.
Argue against your solution.
Give you hints instead of solutions.
AI becomes more valuable when the conversation becomes deeper than:
"Write this for me."
3. From AI Assistance to Human Ownership
Using AI doesn't remove responsibility from the developer.
If AI generated the code, you still need to understand it.
If AI proposed the architecture, you still need to evaluate it.
If AI suggested the fix, you still need to verify it.
If AI made the decision easier, you still need to own the decision.
BY MY SELF means the outcome is mine—even when the assistance wasn't.
4. From Copy-Paste to Understanding
Fast code isn't necessarily good code.
Working code isn't necessarily understood code.
Generated code isn't automatically production-ready code.
If I cannot explain it, test it, modify it, debug it, or defend the decision behind it, then I don't truly own it yet.
Use AI to accelerate understanding—not to bypass it.
5. From Accepting AI's Output to Verifying It
AI can be useful.
AI can also be wrong.
It can misunderstand requirements, make incorrect assumptions, invent APIs, produce insecure code, introduce unnecessary complexity, or recommend something inappropriate for the system.
Therefore:
Generate → Inspect → Question → Test → Verify.
Never confuse confidence with correctness.
6. From Learning With AI to Becoming Capable Without It
AI should increase your capabilities, not hide your weaknesses.
Learn the fundamentals.
Practice without assistance.
Build from scratch.
Debug your own mistakes.
Then bring AI into the process.
The goal isn't to prove that you can work without AI every minute.
The goal is to know that:
AI is helping you—not carrying you.
7. From Programmer to AI-Augmented Engineer
The future isn't simply about writing code faster.
It is about thinking at a higher level.
Understanding requirements.
Designing systems.
Making trade-offs.
Reviewing implementations.
Understanding architecture.
Testing assumptions.
Managing complexity.
Communicating decisions.
Using AI throughout the development lifecycle.
The developer of the future isn't merely someone who knows how to prompt.
It is someone who knows:
what to ask, why to ask it, how to evaluate the answer, and what to do with it.
The BY MY SELF Principle
This is the foundation underneath everything I am building.
LEARN
Understand the concept before rushing to implementation.
THINK
Attempt to reason through the problem yourself.
BUILD
Turn your understanding into something real.
BREAK
Allow yourself to encounter mistakes and unexpected behavior.
DEBUG
Investigate instead of immediately searching for a replacement answer.
UNDERSTAND
Find out why the solution works.
DOCUMENT
Record what you learned so the experience becomes reusable knowledge.
REPEAT
Every project becomes another opportunity to become more capable.
AI belongs inside this cycle.
It does not replace the cycle.
My AI Operating Principle
I don't believe there is a universal percentage that every developer must follow.
But I have a personal rule:
Think more than you delegate.
My goal is to spend more of my effort understanding the problem, reasoning about the solution, making decisions, and verifying results than simply producing output.
If AI is doing all the thinking, I'm not becoming a better developer.
If AI is accelerating work I understand and can evaluate, then it is making me more capable.
AI should accelerate my hands—not replace my mind.
The Commitment
I am not writing this from the position of someone who has already mastered everything.
I'm writing it as a developer in motion.
I'm learning programming.
I'm building projects.
I'm making mistakes.
I'm debugging.
I'm experimenting with AI.
And I'm documenting what happens.
My goal is to become a confident, independent developer who can build real software, explain what I build, understand the decisions behind it, and take responsibility for the work I produce.
I'm building under the name Blessed Codes.
I'm laying the foundation for something bigger called BlexonDevco.
And I'm doing it through one principle:
BY MY SELF.
Not alone.
Not unaided.
But with ownership.
The thinking is mine.
The decisions are mine.
The mistakes are mine.
The growth is mine.
The work carries my name.
AI can help me build it.
But AI cannot become me.
The Invitation
If you're a beginner, learn with me.
If you're an intermediate developer, challenge the ideas.
If you're experienced, challenge the standard.
If you're an architect, challenge the assumptions.
If you're building alone, know that independence does not require isolation.
And if you use AI every day, ask yourself:
Is AI making me better—or merely making me faster?
Because faster isn't always better.
A faster developer who understands less isn't necessarily becoming a stronger engineer.
The goal is capability.
The Future
The developers who thrive alongside AI will not necessarily be those who resist it.
Nor will they necessarily be those who surrender everything to it.
They will be the developers who learn to think with AI while remaining capable of thinking beyond it.
They will know when to ask.
When to investigate.
When to challenge.
When to verify.
When to reject an answer.
And when to put the AI aside and solve the problem themselves.
That is the kind of developer I am working to become.
And this series is the record of that journey.
"I'm no longer just preparing to become a developer. I'm becoming one."
Top comments (0)