DEV Community: ogiri godday

Resilience in the Age of AI: Don’t Compete With AI, Learn to Leverage It

ogiri godday — Mon, 07 Sep 2026 15:31:42 +0000

Resilience in the Age of AI: Don’t Compete With AI, Learn to Leverage It.

There is something different about the way people talk about work these days.You hear things like:

“AI can do that now.” “Why would a company hire someone when AI can do the work?” “My job might not exist in a few years.” And honestly, I understand the fear.

Artificial Intelligence is changing the workplace incredibly fast. Some tasks that once required hours of human effort can now be completed in minutes. Companies are experimenting with AI to reduce costs, automate repetitive work, and increase productivity. For employees, freelancers, and people trying to build their careers, this can feel frightening.
But I believe there is another way to look at it.

Instead of asking, “How do I compete with AI?” we should start asking, “How can I use AI to become better at what I do?” AI is changing jobs, not necessarily eliminating human value I don't think we should pretend that AI won't affect employment. It will.

Some jobs will disappear. Some roles will become smaller. Some responsibilities will be automated. And many existing jobs will change significantly. But technology has always changed the way humans work.
The computer changed the workplace. The internet changed communication. Smartphones changed businesses. Software automated many manual processes.

AI is another major shift. The difference is that AI can now perform tasks that require language, reasoning, analysis, creativity, and pattern recognition. That can certainly feel personal. But your value as a human being is bigger than the tasks you perform.

A job is something you do. It is not the entirety of who you are.
Don't let fear turn into paralysis One of the biggest dangers of the AI revolution may not be AI itself. It may be the fear of AI.

You can become so worried about losing your job that you stop learning.
You see people building amazing things with AI and think: "I'm already behind." Then you become discouraged. Then you stop experimenting.
Then the gap becomes even bigger. I think resilience means doing something different.

When the environment changes, you adapt.
You don't have to become an AI researcher.
You don't have to understand every new AI model.
You don't need to learn 50 different AI tools.
Start with your own field.
Ask yourself:
"What part of my work can AI help me do better?"

Use AI as a multiplier Imagine you are a writer. Instead of seeing AI as the person taking your writing job, learn how to use AI for research, brainstorming, editing, summarizing and generating ideas—while you remain responsible for judgment, originality and the final message.

If you're a developer, don't just worry that AI can generate code.
Learn how to use AI to understand unfamiliar codebases, debug problems, write tests, document systems and build prototypes faster.
If you're a marketer, use AI to analyze data, generate campaign ideas, research audiences and test messaging. If you're a teacher, use it to create learning materials, explain difficult concepts and personalize learning.

If you're a product manager, use AI to analyze feedback, research competitors, organize ideas and accelerate product discovery.
The question is no longer simply: "Can AI do my job?"

A better question is:
"What can I accomplish with AI that I couldn't accomplish as efficiently before?" You don't have to know everything I'm learning this myself.
As I explore AI-assisted software development and product building, I've realized that using AI effectively isn't simply about asking it to generate something and copying the result.

You still need to understand the problem.
You need to ask better questions.
You need to verify what AI produces.
You need to debug it when it doesn't work.
You need to understand the user.
You need to make decisions.
And sometimes, you need to tell the AI:
"No, that's not what I meant. Try again."That's where human capability still matters. AI can give you possibilities. You provide direction.
Build instead of just consuming One of the best ways to overcome the fear of AI is to start building with it. Don't spend all your time watching videos about the future of AI.

Try something. Build a small application. Automate a repetitive task.
Create a personal assistant. Analyze a dataset. Build a website. Use AI to improve your CV. Create a workflow that saves you two hours every week.
You don't need to build the next billion-dollar AI company.
You just need to start. Every small project teaches you something.
And those small experiments gradually become skills.
Resilience doesn't mean pretending everything is fine
Being resilient doesn't mean saying:
"AI won't take any jobs."

That would be unrealistic. Resilience means being able to acknowledge that things are changing and still decide: "I will learn. I will adapt. I will find where I can create value." There will probably be moments when you feel behind. There will be moments when someone younger seems to know more about AI. There will be moments when a new tool makes something you spent weeks learning look easy. That's okay. Your journey isn't supposed to look like someone else's.

Keep learning.
Keep experimenting.
Keep building.

The future belongs to people who adapt I don't know exactly what the workplace will look like five or ten years from now. Nobody does.
But I believe people who develop the ability to learn, adapt, communicate, solve problems and work effectively with technology will have opportunities.

AI doesn't have to be the enemy.
It can be your assistant.
It can be your teacher.
It can be your brainstorming partner.
It can be your coding companion.
It can be your research assistant.
It can help you move from "I don't know how to do this" to "Let me see if I can figure this out." So if you're currently worried about AI taking your job, I completely understand. But don't let that fear convince you that you are useless. Learn the tool. Experiment with it.
Build with it. Become more valuable because of it. The goal isn't to become better than AI at everything. The goal is to become someone who knows how to work with AI to create value.

And perhaps the most important thing to remember is this:
AI may change the way we work, but our ability to learn, adapt, create, connect with people and solve meaningful problems remains deeply human.

ai

community

devchallenge

discuss

I Tried Building an AI-Powered Study Bible. The Hard Part Wasn't Generating the App.

ogiri godday — Mon, 07 Sep 2026 15:03:53 +0000

I Tried Building an AI-Powered Study Bible. The Hard Part Wasn't Generating the App.

When I started building Koinonia Study Bible, I wasn't trying to build another Bible-reading app. I wanted to build a study companion. The idea was simple: a user should be able to read Scripture, understand its context, study it more deeply, and eventually apply what they've learned.
That became the product's guiding idea: Read. Understand. Study. Apply.
The first version looked promising. There was a home screen, a “Continue Reading” section, daily Scripture, devotionals, popular Bible topics, and a personal library. It looked like a real product. And that was the exciting part.

I had used AI to move from an idea to something I could actually interact with. Then I discovered something that became one of the biggest lessons of the project: Making an application look like it works and making it actually work are two very different problems.

The idea behind Koinonia Study Bible Most Bible apps solve the reading problem very well. You open the app, find a book, choose a chapter, and read. I wanted to go further. What if a reader could move naturally from a verse into deeper study? A verse could have its surrounding context, cross-references, different Bible translations, textual observations, theological interpretation, devotional application and personal notes.
The goal wasn't to replace serious Bible study. It was to make the tools required for study easier to access. That meant the application had to understand something fundamental: Scripture is structured data. A Bible isn't simply a very long block of text. It has:
• Books
• Chapters
• Verses
• Translations
• References
• Relationships between passages

And once interpretation is added, there is another layer: the interpretation has to belong to the right passage. That sounds obvious.
It became surprisingly important. AI made the first version possible
One of the reasons I chose an AI-powered app-building approach was speed. Instead of starting with a blank development environment and manually constructing every screen, I could describe what I wanted and iterate quickly.

I could explain the product concept, describe a screen, ask for a change and see another version. That dramatically lowered the barrier between “I have an idea” and “I have something I can use.” The first prototype gave me something valuable that a specification document couldn't:
feedback. I could interact with the product. I could see what made sense. I could discover what was missing.

And, more importantly, I could discover what was wrong. Then the interesting problems started One of the biggest surprises was that some of the problems weren't visual at all. The interface could look perfectly reasonable while the underlying behaviour was wrong. For example, at one point I encountered problems with Bible verse sequencing. Instead of moving through Scripture correctly, the application could show some verses and then jump unexpectedly.

Other problems appeared around contextual analysis. I wanted the application to provide exegesis and theological interpretation for the specific passage a user was studying. But an AI system can produce a perfectly grammatical, convincing-looking explanation without necessarily proving that it has correctly associated that explanation with the selected verse. That's a dangerous distinction. A response can sound right and still be wrong for the user's context. For a general productivity application, that might be an annoying bug. For a study Bible, it affects trust. If I select one verse and receive analysis that actually belongs to another verse, the application has failed at one of its most important jobs.

The problem wasn't really the AI This was probably one of my biggest lessons. My first instinct could have been to say: “The AI isn't working properly.” But that explanation is too simple. The deeper problem was the relationship between the AI, the application's data and the user's current state. An AI model can generate an interpretation.
But something else needs to answer questions such as:
• Which book did the user select?
• Which chapter?
• Which verse?
• Which translation?
• What exact Scripture text belongs to that reference?
• What information should be retrieved?
• What information should be generated?
• What should be stored?
• When should previously generated content be reused?

Those are application architecture questions. They're not solved simply by making the prompt longer. Generating content isn't the same as retrieving the right content. This distinction changed how I thought about the project. Suppose a user selects: John 3:16. The application shouldn't ask an AI model to somehow “know” what John 3:16 is every time. The Bible text should come from a reliable, structured source.

The application should know that: John → Chapter 3 → Verse 16 is a specific piece of data. Then the AI layer can work on top of that information. Conceptually, the system becomes something closer to: Bible data → selected passage → relevant context → AI analysis → stored result → user rather than: User → AI → hopefully correct answer That distinction seems obvious to me now. It wasn't as obvious when I started. The interface can hide architectural problems This is another thing AI-assisted development taught me.

AI is extremely good at producing interfaces that look complete.

A homepage can have beautiful cards.
A Bible screen can have buttons.
A verse can have an “Exegesis” option.
A search box can exist.

But the existence of those components doesn't mean the underlying system is correctly implemented. For example, a toolbar might show Book and Chapter selectors, but if the user can't reliably select a specific verse, the interface hasn't solved the navigation problem. A button labelled “Notes” doesn't mean notes are actually being persisted correctly.

An AI-generated interpretation doesn't mean it is properly associated with the passage that produced it. This created a useful mental model for me:
The UI demonstrates what the product wants to do. The data model determines whether the product actually can do it. What I would do differently

If I were designing the application again from the beginning, I would put much more emphasis on the underlying data model before worrying about adding more features. I'd want the Bible structure to be deterministic. Something like:
Book
Chapter
Verse
Translation
Passage context

Then the AI functionality becomes a layer that operates on retrieved information rather than being responsible for supplying the fundamental Scripture data itself. I'd also separate generated study material from the Bible text itself.
For example, an exegesis record could be associated with a precise Scripture reference rather than simply being stored as a piece of text that the interface happens to display. That makes it possible to ask better questions:

Which passage does this analysis belong to?
Was it generated already?
Can I retrieve it immediately?
Does it need to be regenerated?
Which model or prompt generated it?

Those questions become increasingly important as the application grows.
The product is still unfinished. Koinonia Study Bible is still a work in progress. That's important to say because the project hasn't reached the point where I can claim that every problem has been solved. But I don't see that as a failure. The unfinished state is actually what has made the project useful to me.

I started with a product idea. AI helped me turn that idea into something tangible very quickly. Then the prototype exposed problems I wouldn't have discovered from a concept document. Those problems forced me to think more deeply about data, retrieval, application state, user experience and the boundary between deterministic software and generative AI. In other words, the prototype became a teacher. What building it changed about how I see AI development

Before this project, I was mostly thinking about AI as a way to make software development faster. Now I think about it differently.
AI can dramatically reduce the cost of experimentation. It can help someone move from an idea to a prototype. It can generate components, suggest implementations and help bridge the gap between product thinking and technical execution. But there is a limit.

AI can generate a lot of software before you've actually solved the architecture. And that can create a dangerous illusion of progress. You can have ten screens and still not have a reliable product. You can have an impressive demo and still have a broken data model. You can have an intelligent model generating text and still have no guarantee that it is generating the right text for the right context.

For me, that's probably the biggest lesson from Koinonia Study Bible.
The hardest part wasn't generating the app. It was deciding what the application should trust the AI to do and what the application itself needed to control. And I'm still building.

DEV Community: ogiri godday

Resilience in the Age of AI: Don’t Compete With AI, Learn to Leverage It

ai

community

devchallenge

discuss

meta

I Tried Building an AI-Powered Study Bible. The Hard Part Wasn't Generating the App.

ai

webdev

productmanagement

beginners