DEV Community: Louis

Has Vibe Coding Made Junior Developers Better or Worse at Learning Software Engineering?

Louis — Wed, 10 Jun 2026 09:32:26 +0000

Over the past year, AI coding tools have gone from being helpful assistants to becoming part of many developers' daily workflows. Some developers are shipping features in hours instead of days, building side projects faster than ever, and spending less time on repetitive tasks.

At the same time, concerns about code quality, maintainability, and long-term technical debt keep coming up. It's easy to generate working code, but is it always code that teams want to maintain six months later?

Some engineers argue that vibe coding is simply the next evolution of software development, similar to how frameworks, libraries, and cloud platforms changed the way we build software. Others believe we're trading short-term speed for long-term complexity.

I'm curious how this looks in the real world.

Have AI coding tools genuinely made you more productive, or have they introduced new challenges that weren't there before? Have you ever shipped AI-generated code that later became difficult to maintain? On the flip side, have these tools helped you solve problems that would have taken much longer otherwise?

For those working in teams, has vibe coding changed your code review process, engineering standards, or hiring expectations?

Would love to hear both success stories and cautionary tales. What has your experience been so far?

The $100M AI Mistake: Teaching Models Instead of Connecting Data

Louis — Wed, 10 Jun 2026 06:27:55 +0000

The AI industry has become obsessed with making models smarter.

Every week brings another announcement about larger context windows, more parameters, faster inference, or improved reasoning benchmarks. Companies spend millions evaluating models, comparing vendors, and debating whether the next upgrade will finally unlock the AI transformation they've been promised.

Yet many organizations are discovering an uncomfortable truth.

The biggest obstacle to successful AI isn't intelligence.

It's access.

An AI system can be incredibly smart and still completely useless if it doesn't have access to the information people actually need.

That's where many expensive AI initiatives begin to fall apart.

The Enterprise AI Reality Check

Almost every AI project starts with an impressive demo.

A chatbot answers questions.

A virtual assistant summarizes documents.

An internal tool retrieves information from a knowledge base.

Executives see the demonstration and immediately imagine the productivity gains.

Then the system reaches real users.

Someone asks about a policy that changed last week.

A customer requests information about a newly launched product.

A support agent searches for an answer buried inside thousands of internal documents.

Suddenly the AI starts struggling.

Not because the model lacks intelligence, but because it lacks context.

The information it needs either doesn't exist in its training data or isn't available in the format required to generate accurate responses.

The result is predictable: confident answers, outdated information, and frustrated users.

Why Bigger Models Aren't Fixing the Problem

When AI systems fail, the first instinct is often to upgrade the model.

Maybe the next generation of AI will solve it.

Maybe a different provider will solve it.

Maybe fine-tuning will solve it.

But smarter reasoning cannot compensate for missing information.

Imagine hiring the world's most knowledgeable consultant and asking them questions about a company they've never worked with.

No matter how intelligent they are, they'll eventually start guessing.

That's effectively what happens when organizations expect large language models to answer questions without direct access to current business data.

The issue isn't intelligence.

The issue is visibility.

The Shift From Training to Retrieval

A growing number of engineering teams are beginning to rethink the problem entirely.

Instead of trying to teach AI everything in advance, they're focusing on helping AI find the right information at the moment it's needed.

This is the idea behind Retrieval-Augmented Generation (RAG).

Rather than relying solely on what a model learned during training, RAG enables systems to retrieve relevant information from company documents, databases, internal tools, and knowledge repositories before generating a response.

The difference sounds subtle.

In practice, it's massive.

One system answers based on memory.

The other answers based on reality.

The Hidden Cost of Disconnected Data

Many organizations underestimate how fragmented their information actually is.

Important knowledge is spread across CRMs, support platforms, internal wikis, cloud storage systems, emails, databases, and collaboration tools.

Humans have learned to navigate this complexity over time.

AI systems haven't.

Without proper retrieval architecture, even the most advanced model is forced to operate with an incomplete picture of the business.

This creates a dangerous situation.

The AI appears confident.

Users assume it's correct.

But the underlying information may be outdated, incomplete, or entirely missing.

For industries like healthcare, finance, insurance, and enterprise software, those mistakes can become extremely expensive.

The Companies Getting AI Right

The organizations seeing the strongest results from AI aren't necessarily using the most powerful models.

They're building better connections between AI and their data.

Instead of treating AI as a standalone tool, they're treating it as an intelligent layer that sits on top of existing business systems.

When a user asks a question, the AI retrieves current information before generating an answer.

That simple architectural shift often delivers a greater improvement than switching to a newer model.

This is a perspective highlighted by GeekyAnts in its article on integrating RAG into existing application architectures. Rather than focusing solely on model selection, the company emphasizes retrieval strategies, architecture design, tooling decisions, and cost considerations that help AI systems stay connected to real business data.

Source: https://geekyants.com/blog/how-to-integrate-rag-into-your-existing-application-architecture-tools-and-cost-breakdown

The smartest AI in the world cannot help if it cannot find the information it needs.

The Rise of Zero-Copy Thinking

Another trend emerging in enterprise AI is the move away from duplicating data.

Historically, organizations copied information into separate systems to make it searchable by AI.

The problem is that copied data eventually becomes stale.

Teams then spend months maintaining synchronization pipelines between systems.

Many modern architectures are moving toward a different approach.

Instead of creating additional copies, they connect AI directly to trusted sources of information.

This reduces maintenance overhead while improving data freshness and reliability.

More importantly, it keeps AI aligned with the current state of the business rather than a snapshot from months ago.

Trust Will Define the Winners

The future of enterprise AI won't be determined by which company uses the largest model.

It will be determined by which company builds the most trusted system.

Trust comes from consistency.

Consistency comes from accuracy.

Accuracy comes from access to reliable information.

That's why the next phase of AI adoption is becoming less about model intelligence and more about information architecture.

The organizations that recognize this shift early will move beyond flashy demonstrations and build AI products people genuinely rely on.

The rest may continue spending millions teaching models information they should simply be retrieving.

And that could become the most expensive AI mistake of all.

From Build vs Buy to Production Reality: What Insurance AI Actually Requires

Louis — Fri, 22 May 2026 05:57:24 +0000

Insurance companies are under pressure to move faster with AI. Claims automation, underwriting support, fraud detection, customer assistance, billing optimization, every part of the industry is being pushed toward intelligent systems. But while AI adoption has accelerated, many insurance companies are running into the same problem: the pilot works, the production rollout does not.

That gap between experimentation and real-world execution is becoming one of the biggest challenges in enterprise AI today.

A lot of organizations still approach AI with a simple question: should we build it ourselves or buy an existing solution? In reality, the answer is rarely that straightforward. The companies seeing long-term success are treating AI less like a tool purchase and more like a system design problem.

This is especially true in insurance, where compliance, legacy infrastructure, and operational complexity make production environments far more difficult than controlled demos.

GeekyAnts has explored this shift across several insurance and healthcare AI implementations, particularly around production-ready systems and long-term scalability.

The Problem With the “Build vs Buy” Debate

For years, enterprise AI conversations revolved around whether companies should build internal AI systems or purchase ready-made solutions from vendors. That approach made sense when AI adoption was still early.

Today, most insurance companies use a mix of both.

There are certain areas where buying makes complete sense. Commodity capabilities like OCR, transcription, or basic support automation do not always need heavy internal engineering. Buying these systems can reduce time to market and avoid unnecessary infrastructure costs.

But the moment AI starts influencing underwriting decisions, claims workflows, or risk evaluation, the conversation changes completely.

Those systems are tied directly to how insurance businesses operate. They involve internal logic, proprietary data, and compliance-sensitive processes. Outsourcing too much of that intelligence creates dependency and limits flexibility over time.

At the same time, building everything internally is not realistic either. Maintaining AI infrastructure, monitoring models, handling data pipelines, and continuously retraining systems requires significant engineering maturity.

That is why most enterprise insurance systems are moving toward hybrid AI architectures instead of choosing one side completely.

Modern insurance platforms also require strong frontend experiences and connected digital ecosystems. Teams working on enterprise dashboards and customer-facing portals often rely on resources from UI UX Designing and Web Application Developments to better understand scalable product experiences around enterprise software.

Why AI Projects Struggle After the Pilot Stage

One of the biggest misconceptions around enterprise AI is that a successful pilot means the hard part is done.

In reality, pilots are often the easiest phase.

Pilot environments are controlled. The datasets are cleaner. The workflows are simplified. Edge cases are limited. Production systems are the exact opposite.

Once AI enters real insurance workflows, problems start appearing quickly. Data comes from multiple disconnected systems. Legacy infrastructure creates inconsistencies. Regulatory requirements slow deployment decisions. Human review layers complicate automation.

Many AI systems are built with strong models but weak operational foundations.

That is why companies frequently see impressive demo results but disappointing adoption after rollout.

The issue usually is not that the AI failed technically. The issue is that the surrounding system was never designed properly for production use.

For organizations building mobile-first insurance experiences, especially around claims and customer support workflows, platforms like Mob App Development and Flutter Geek Hub frequently discuss scalable mobile engineering approaches for enterprise products.

Production AI Is Mostly an Engineering Problem

There is a tendency to treat AI as primarily a modeling challenge. In insurance, it is often an engineering challenge first.

A claims prediction model might achieve excellent accuracy in testing, but if it cannot integrate smoothly into claims processing workflows, it becomes difficult to use operationally. Teams stop trusting it. Adoption slows down. Eventually the system becomes another disconnected dashboard that no one relies on.

Production systems require far more than good predictions.

They need reliability, monitoring, governance, explainability, and stable integrations with existing workflows. They also need to handle changing regulations and evolving business rules without constant rebuilding.

This is where many insurance AI projects fail quietly. The focus stays on model performance while operational resilience gets ignored.

As more insurance companies adopt AI-powered web platforms, frameworks like Next.js are also becoming increasingly common for enterprise applications. Communities such as NextJS ReactJS and React Native Coders often explore frontend performance and scalable architecture patterns that support AI-driven products.

Why Explainability Matters More in Insurance

Unlike consumer apps, insurance AI systems cannot operate as black boxes.

Every major decision can carry financial, legal, or regulatory implications. If an AI system flags a claim, adjusts a premium, or influences underwriting outcomes, organizations must be able to explain why that decision happened.

That requirement changes how AI systems need to be built.

It is not enough for a model to be accurate. The organization also needs visibility into how outputs are generated, how data is processed, and how decisions can be audited later.

This becomes especially important as AI regulations continue evolving globally.

Insurance companies that ignore explainability early often end up rebuilding large parts of their systems later.

Strong backend architecture also plays a major role here. Reliable APIs, audit logging systems, and infrastructure monitoring are essential for explainable AI systems in regulated industries. Resources from Backend Application and DevOps Connect Hub often focus on these operational engineering challenges.

The Shift Toward Hybrid AI Systems

The most mature AI strategies in insurance are no longer fully internal or fully vendor-driven.

Instead, companies are separating AI into layers.

Core business intelligence, underwriting logic, and proprietary workflows are usually kept internal. These areas define competitive advantage and require tighter governance.

Meanwhile, external AI services are used where they add speed or flexibility without exposing critical business logic.

This hybrid approach allows organizations to move faster without losing control over the systems that matter most.

It also reduces long-term vendor dependency while making future upgrades easier.

That flexibility is becoming increasingly important because the AI ecosystem changes rapidly. Models improve quickly. Vendors evolve. Regulations shift. Insurance companies need architectures that can adapt without requiring full system rebuilds every year.

As enterprises experiment with faster AI deployment cycles, low-code workflows and AI productivity platforms are also becoming part of the conversation. Platforms like Low Code No Code Tool and AssistGPT highlight how teams are accelerating internal operations and AI-assisted workflows without rebuilding everything from scratch.

Moving Beyond AI Pilots

The insurance industry is slowly moving past the phase where AI experimentation alone creates value.

Now the focus is shifting toward operational maturity.

Companies are asking different questions:

Can the system scale across teams?
Can it survive compliance reviews?
Can it integrate with existing workflows?
Can it remain reliable over time?

Those questions are far more important than whether a pilot demo looks impressive.

Organizations that succeed with AI over the next few years will likely be the ones that focus less on chasing models and more on building durable systems around them.

That shift from “AI feature thinking” to “AI infrastructure thinking” is where the industry is headed.

Final Thoughts

Insurance AI is entering a more practical phase. The excitement around pilots and experimentation is still there, but companies are becoming more realistic about what it actually takes to deploy AI successfully at scale.

The real challenge is no longer proving that AI can work.

The challenge is building systems that continue working long after the demo ends.

That requires better architecture decisions, stronger operational engineering, and a clearer understanding of where to build internally versus where to rely on external tools.

Companies like GeekyAnts are increasingly focusing on this production-first approach, helping enterprises move from isolated AI initiatives toward scalable, reliable systems designed for real-world insurance operations.

Why Complex React Native Forms Still Break in 2026

Louis — Tue, 19 May 2026 10:01:50 +0000

Building mobile apps with React Native has become significantly faster over the last few years. Teams can now ship polished interfaces, integrate AI powered workflows, and deploy updates across platforms without maintaining two separate codebases.

But one issue still frustrates developers working on production apps:

The keyboard.

Not the simple “keyboard covers the input field” problem. Most developers already know how to solve that with basic layout handling. The real challenge begins when screens become more dynamic, interactive, and state heavy.

Multi step forms, chat interfaces, bottom sheets, nested scroll views, sticky footers, and animated layouts can turn keyboard interactions into an unpredictable mess. Inputs jump unexpectedly, layouts flicker, scroll positions reset, and users end up fighting the UI instead of completing tasks.

A detailed engineering article from GeekyAnts explored this exact problem through what many developers jokingly call the “keyboard bounce of death.” The article highlighted how seemingly small layout decisions in React Native can create cascading UX issues in complex screens.

This post expands on those ideas from a broader production engineering perspective and explains why keyboard handling remains one of the most underestimated challenges in mobile app development.

Why Keyboard Handling Gets Worse as Apps Scale

Simple login screens rarely expose keyboard related problems.

The issues start appearing when applications include:

Dynamic forms
Multiple nested components
Conditional rendering
Scrollable containers
Real time validation
Animated transitions
Sticky action buttons
Bottom navigation
Modals and sheets

In these situations, the keyboard becomes part of the layout system itself.

When the keyboard appears, the application must suddenly recalculate available screen space, adjust scrolling behavior, preserve focus states, maintain animation timing, and ensure touch interactions still work correctly.

That is difficult enough on one platform.

Now add:

Different Android keyboard implementations
iOS safe area behavior
Device specific viewport sizes
Gesture navigation
Orientation changes
Third party UI libraries

The complexity grows rapidly.

Many teams underestimate this until QA testing begins across real devices.

The Hidden Cost of Keyboard Bugs

Keyboard issues are often dismissed as “minor UI bugs.”

In reality, they directly affect business outcomes.

A broken checkout form can reduce conversions.

A frustrating onboarding flow can increase abandonment.

A laggy healthcare or fintech form can reduce trust in the product itself.

Users may never describe the issue technically. They simply say:

“This app feels annoying.”

That perception matters.

For enterprise mobile applications, keyboard handling becomes even more important because workflows are frequently data intensive. Employees may spend hours interacting with forms, inputs, filters, and operational dashboards.

Small interaction problems repeated hundreds of times per day create major usability friction.

Why Basic Fixes Stop Working

Most React Native developers initially rely on components like:

KeyboardAvoidingView
ScrollView
SafeAreaView

These work well for straightforward layouts.

But production applications often combine all of them simultaneously with:

Animated headers
Gesture driven navigation
Tab systems
Bottom sheets
Virtualized lists
Floating buttons
Custom modals

At that point, default keyboard avoidance strategies begin conflicting with each other.

For example:

One container adjusts padding
Another recalculates height
A third triggers scrolling
The keyboard animation updates mid transition

The result is the infamous “bounce” effect where layouts shift multiple times before settling.

This creates a visibly unstable interface.

Android vs iOS: Two Different Worlds

A major reason keyboard handling becomes difficult in React Native is platform inconsistency.

On iOS, the keyboard behavior is generally more predictable because the operating system handles layout transitions consistently.

Android is far more fragmented.

Different manufacturers implement keyboards differently. Some resize the viewport. Others overlay content. Some trigger delayed layout recalculations.

Even the same screen can behave differently depending on:

Keyboard app
Android version
Navigation mode
Device dimensions

This is why developers often report:

“Works perfectly on my simulator.”

Production reality is rarely that simple.

Complex Screens Create Compound Problems

Modern mobile screens are no longer static pages.

A single screen may include:

API driven content
Interactive cards
Auto expanding text inputs
Embedded media
Live validation
Keyboard aware animations
Floating toolbars

Each component may independently react to layout changes.

This creates cascading re renders and unstable positioning.

One of the most important lessons highlighted in the original GeekyAnts engineering article is that keyboard issues are rarely caused by one isolated component.

They are usually the result of multiple layout systems competing simultaneously.

That distinction matters because it changes how teams should debug the issue.

Instead of fixing a single input field, developers often need to rethink the entire screen architecture.

Performance Matters More Than Developers Expect

Keyboard interactions are highly sensitive to performance problems.

Even small delays become noticeable because the user is actively typing.

If rendering blocks the UI thread during keyboard transitions:

Animations stutter
Inputs lose focus
Scroll positioning breaks
Touch responsiveness drops

In production applications, this frequently happens because screens are overloaded with logic.

Heavy state updates during input interactions are especially dangerous.

Examples include:

Form validation on every keystroke
Expensive re renders
API requests triggered during typing
Complex animations tied to layout changes

The keyboard exposes these bottlenecks immediately.

Better Architecture Reduces Keyboard Problems

One pattern increasingly adopted by experienced mobile teams is reducing layout coupling.

Instead of making the entire screen keyboard aware, teams isolate keyboard sensitive regions.

For example:

Keep forms inside dedicated scroll containers
Avoid deeply nested keyboard aware wrappers
Separate animations from layout calculations
Minimize unnecessary state updates during typing
Use predictable container hierarchies

This approach improves maintainability while reducing layout conflicts.

The goal is not just “making the keyboard work.”

The goal is making keyboard behavior stable across devices and future UI updates.

Testing Keyboard Behavior Should Be Mandatory

Many keyboard related issues are never caught during development because teams rely too heavily on simulators.

Real device testing is essential.

Particularly for:

Android OEM devices
Small screen phones
Foldables
Landscape orientation
Third party keyboards

Teams should also test:

Long forms
Rapid focus switching
Dynamic validation
Modal interactions
Split screen behavior

Keyboard handling should be treated as a core QA workflow rather than a final polish task.

Why This Problem Will Continue

Ironically, modern mobile development trends are making keyboard management harder.

Applications increasingly rely on:

AI assisted interfaces
Conversational UI
Dynamic content rendering
Real time collaboration
Complex interactive workflows

All of these patterns increase input complexity.

As screens become smarter and more adaptive, layout coordination becomes more fragile.

That means keyboard engineering is no longer just a frontend concern.

It is becoming part of overall product reliability.

Final Thoughts

The hardest engineering problems are often not the flashy ones.

They are the subtle interaction details users notice immediately when they fail.

Keyboard handling in React Native is a perfect example.

The original engineering write up from GeekyAnts brought attention to an issue many mobile teams quietly struggle with during production scaling.

As applications become more interactive and interface complexity increases, stable keyboard behavior will remain a critical part of delivering polished mobile experiences.

Because users may never compliment perfect keyboard handling.

But they instantly notice when it breaks.