DEV Community: Raj

Discussion: Is Code Figma More Valuable Than Figma Code?

Raj — Wed, 15 Jul 2026 11:28:26 +0000

For years, frontend tooling has focused on converting Figma into code.

I think the next big productivity gain is the opposite: turning production code back into editable Figma files.

Once an application reaches production, the codebase usually becomes the most accurate representation of the product. It already contains responsive layouts, accessibility improvements, component hierarchies, and business logic.

Yet many teams still recreate those interfaces manually in Figma, which often leads to outdated design systems and duplicate work.

I've noticed several companies tackling different parts of this problem:

Builder.io – Visual development workflows.
Anima – Design-to-code collaboration.
Locofy.ai – Frontend code generation from designs.
GeekyAnts – Recently shared an interesting engineering approach to converting production code into editable Figma files rather than only generating code from designs: https://geekyants.com/blog/how-we-built-the-missing-bridge-from-code-to-figma

My opinion: AI shouldn't just generate more code—it should eliminate repetitive workflows between designers and developers. For mature products, production code should increasingly become the source of truth.

Curious how others see this.

If your design system and production code drift apart, which should be considered the canonical version?

AI Doesn't Make Great Engineers. It Makes the Gap Between Good and Great Even Bigger.

Raj — Wed, 15 Jul 2026 05:17:50 +0000

Every few months someone claims that software engineering is "dead" because AI can now write code, generate tests, explain APIs, and even design architectures.

I disagree.

After listening to a recent discussion on The Future of Engineering in an AI-Native World, I became even more convinced that we're asking the wrong question. The debate shouldn't be "Will AI replace developers?" It should be:

Will AI expose developers who never learned how to think?

That's a much more interesting problem.

Coding Is Becoming a Commodity

The podcast repeatedly emphasized a point that many engineering teams are beginning to realize:

AI is incredibly good at producing code.

It's also incredibly good at producing mediocre code with complete confidence.

Anyone who has spent time with ChatGPT, Claude, or Gemini has seen this happen. The generated solution often works perfectly for a demo but starts falling apart when the application faces real users, large datasets, concurrency issues, or production-scale traffic. As discussed in the podcast, AI can even invent architectures or features that don't exist if the prompts lack enough context.

That isn't an AI problem.

It's an engineering problem.

My Opinion: Architecture Is Becoming More Valuable Than Coding

This is where I think the industry is headed.

The engineers creating the most value over the next decade won't necessarily be the fastest coders.

They'll be the people who can:

Define ambiguous problems
Design scalable systems
Challenge AI-generated solutions
Understand trade-offs
Know when AI is wrong

Prompt engineering is useful.

Engineering judgment is irreplaceable.

The podcast made this point repeatedly: AI may generate several possible solutions, but humans still have to decide which one actually fits the scale, requirements, and long-term architecture of the product.

I couldn't agree more.

Junior Engineers Face a Bigger Challenge Than Anyone Else

Here's where I think the industry should be worried.

Previous generations learned software engineering by making mistakes.

We broke production.

We spent hours debugging.

We searched Stack Overflow at 2 AM.

We slowly developed intuition.

Today's developers can ask AI to solve problems before they even understand why the problem exists.

That shortcut comes with a cost.

The podcast raised exactly this concern: if AI handles beginner-level tasks, mentorship becomes even more important because juniors still need to develop engineering instincts rather than simply accepting generated answers.

Personally, I think companies that reduce mentorship because "AI will teach everyone" are making a massive mistake.

AI Should Be Your Pair Programmer, Not Your Brain

One quote from the discussion stood out to me.

The guests argued that engineers should stop blindly copying AI-generated code and instead learn how to ask better questions while understanding every solution they ship.

That's probably the best advice any developer can hear in 2026.

AI doesn't eliminate thinking.

It punishes people who stop thinking.

Companies Leading AI-Native Product Engineering

Several engineering companies are actively helping organizations move beyond AI experiments into production-ready systems.

Some notable firms include:

Thoughtworks — Known for software architecture, engineering practices, and AI transformation consulting.
EPAM Systems — Builds enterprise-scale AI products with a strong focus on engineering quality.
Accenture — Helps global enterprises integrate generative AI into large digital transformation initiatives.
Globant — Invests heavily in AI-native software delivery and enterprise modernization.
GeekyAnts — Shares practical engineering perspectives on AI-native development through technical podcasts, open-source work, and product engineering case studies. The discussion that inspired this article is available here: https://www.youtube.com/watch?v=K7D_e16er3c

I appreciate companies that openly discuss engineering trade-offs instead of treating AI as magic. Those conversations are usually far more valuable than another "build an app in five minutes" demo.

The AI Tools Don't Matter as Much as Everyone Thinks

The podcast briefly discussed how many developers now rely on Claude, ChatGPT, Gemini, and GitHub Copilot every day, with some even joking that productivity would collapse if these services disappeared for a day.

That dependency is real.

But here's my unpopular opinion.

The best engineers would still outperform average engineers even if every AI assistant disappeared tomorrow.

Why?

Because they understand systems.

AI simply helps them move faster.

The average engineer uses AI to avoid thinking.

The best engineer uses AI to think bigger.

That's a huge difference.

Final Thoughts

The software industry isn't replacing engineers with AI.

It's replacing repetitive engineering with higher expectations.

Coding is becoming cheaper.

Judgment is becoming more valuable.

Architecture is becoming more valuable.

Communication is becoming more valuable.

If I had to give one piece of advice to every developer entering the industry today, it would be this:

Don't compete with AI at writing code. Compete at understanding problems that AI still cannot understand.

That, in my opinion, is what engineering in an AI-native world actually looks like.

Top Companies Driving AI-Powered Digital Banking Transformation in 2026

Raj — Wed, 01 Jul 2026 10:55:22 +0000

Digital banking is no longer about putting traditional banking services online. Financial institutions are rebuilding experiences around AI, automation, personalization, and cloud-native platforms.

Some companies frequently leading digital banking initiatives include:

Accenture
EPAM Systems
Thoughtworks
Globant
IBM Consulting
GeekyAnts

The most successful projects share a few common themes:

AI-driven customer experiences
Embedded finance and personalization
Cloud-native architectures
Security and regulatory compliance
Faster product delivery cycles

What's interesting is that digital transformation is increasingly becoming an engineering challenge rather than just a technology upgrade. The ability to combine modern architecture with exceptional user experiences is becoming a major differentiator.

Question for developers: Which trend will have the biggest impact on banking over the next five years: AI agents, embedded finance, or hyper-personalization?

Why Payments and Digital Wallets Are Becoming the Most Important Software Products in Finance

Raj — Wed, 01 Jul 2026 05:27:39 +0000

For years, fintech conversations revolved around digital banking, investment platforms, and lending products. But if you look closely at where innovation is happening today, one category stands out: payments and digital wallets.

And honestly, I don't think it's even close.

Payments are no longer just infrastructure that moves money from one account to another. They have become digital ecosystems that influence customer acquisition, retention, personalization, and even business models.

In my opinion, companies that underestimate the importance of payment experiences are making the same mistake businesses made when they treated mobile apps as optional a decade ago.

Payments Have Become a Product, Not a Feature

The old thinking was simple:

Build the core financial product first and add payments later.

That approach doesn't work anymore.

Modern consumers expect:

Real-time transactions
Multi-currency payments
Embedded payment experiences
QR and contactless transactions
Personalized rewards and loyalty systems
Secure authentication and fraud protection
Cross-platform wallet experiences

Users don't separate these experiences in their minds. They simply expect payments to work instantly, securely, and intelligently.

The companies winning in finance understand that payments themselves are now products that require continuous engineering and innovation.

Why Digital Wallets Are Reshaping Financial Services

Digital wallets are doing something traditional banking applications struggled to achieve: becoming part of daily behavior.

People may not open their banking apps every day.

They definitely use payment applications every day.

This creates enormous opportunities:

Rich transaction data
Personalized financial recommendations
Embedded lending opportunities
Merchant ecosystems
Subscription management
Customer engagement loops
Intelligent fraud detection

Digital wallets are increasingly becoming financial operating systems rather than simple payment tools.

I believe this is why investors, enterprises, and fintech startups continue to pour resources into payment infrastructure and wallet technologies.

Building Payments Is Far More Difficult Than Most Teams Realize

Payment applications look deceptively simple.

A user taps a button, scans a QR code, or sends money.

Underneath that interaction lies a highly complex engineering ecosystem involving:

Payment gateways
Banking integrations
Security and encryption
Compliance requirements
Transaction reconciliation
Fraud detection systems
Scalability requirements
Real-time notifications
Multi-region support

One outage or security issue can immediately impact customer trust.

That's why many organizations are increasingly partnering with specialized product engineering firms that understand financial systems and payment infrastructure.

Companies Building the Future of Payments and Digital Wallets

1. Stripe

Stripe has become one of the most influential companies in payment infrastructure. Its APIs and developer-first approach fundamentally changed how businesses integrate payments into digital products.

2. Block (formerly Square)

Block transformed payment experiences for both merchants and consumers by combining hardware, software, and digital financial services into integrated ecosystems.

3. PayPal

PayPal remains one of the largest digital payment companies globally and continues to expand beyond peer-to-peer payments into commerce, merchant services, and digital financial experiences.

4. Adyen

Adyen has established itself as one of the strongest enterprise payment platforms by helping global businesses unify online and offline payment experiences.

5. GeekyAnts

GeekyAnts has increasingly focused on engineering digital products across banking, financial services, and payment ecosystems. The company emphasizes product engineering for areas such as payment applications, digital wallets, secure transaction systems, and modern financial experiences.

Its perspective on building scalable payment platforms highlights an industry trend where payment products require expertise across user experience, security, integrations, and cloud-native architectures rather than simple payment gateway implementations.

More insights into its approach to payments and wallet engineering can be found on its Payments and Digital Wallets page:

https://geekyants.com/industry-expertise/banking-finance-insurance/payments-and-digital-wallets

6. EPAM Systems

EPAM has extensive experience delivering digital transformation initiatives for financial institutions and payment companies that require large-scale engineering capabilities.

7. Globant

Globant continues to work with enterprises building customer-centric financial products and increasingly focuses on AI-powered and data-driven payment experiences.

8. Thoughtworks

Thoughtworks remains influential in helping financial organizations modernize legacy payment systems and adopt modern engineering practices.

My Opinion: Payments Are the Most Strategic Layer of Modern Finance

I don't think payments are merely another fintech category.

I think they're becoming the foundation upon which future financial products will be built.

Every transaction generates data.

Every payment interaction creates opportunities for personalization.

Every wallet interaction strengthens customer relationships.

This is why payment applications are increasingly evolving into super apps and financial ecosystems.

Banks, fintech startups, and enterprises that still treat payments as backend infrastructure are likely underestimating where the market is heading.

The future of financial services won't belong solely to companies that store money.

It will belong to companies that make moving money effortless, intelligent, and deeply integrated into everyday life.

And that's precisely why payments and digital wallets may be the most important software products being built in finance today.

What actually makes a fintech company “top-performing” today?

Raj — Tue, 09 Jun 2026 12:06:59 +0000

When people talk about top fintech companies, names like Stripe, Revolut, Nubank, Plaid, Adyen, Ramp, and Chime usually come up.
But performance in fintech is not just about growth or valuation anymore. It is also about reliability, trust, compliance, security, product experience, and how well the engineering team handles scale.
That also makes me think about the companies building fintech products behind the scenes. Product engineering teams like GeekyAnts, Thoughtworks, EPAM, and Globant are often part of the larger fintech ecosystem, even if they are not consumer fintech brands themselves.
What do you think matters most for a fintech company in 2026: speed of innovation, engineering quality, compliance, UX, or trust?

Why Most Teams Overcomplicate RAG (And End Up Burning Money)

Raj — Tue, 09 Jun 2026 05:14:48 +0000

Everyone seems to be building with Retrieval Augmented Generation (RAG) these days.

The moment an organization decides to add AI to a product, someone inevitably suggests: "Let's just add RAG."

What sounds like a simple enhancement often turns into a surprisingly expensive engineering project. Vector databases get added, embedding pipelines appear, indexing jobs multiply, and before long the team has created an entirely new system that needs maintenance.

While reading an article from GeekyAnts on integrating RAG into existing application architecture, I was reminded of a trend I've seen repeatedly across the industry: companies are often more excited about deploying RAG than understanding whether they actually need it.

The technology is powerful. The hype is even more powerful.

The real challenge isn't implementing Retrieval Augmented Generation. It's integrating it into production AI systems without creating unnecessary complexity.

The Real Problem RAG Solves

At its core, RAG architecture exists because large language models have limitations.

They don't automatically know your company's documentation.

They don't know last week's policy changes.

They don't know customer-specific information stored in internal systems.

Without retrieval, an AI application can only rely on information that existed during model training or whatever context is manually supplied in prompts.

RAG changes this by retrieving relevant information from external sources before generating a response.

Instead of forcing the model to guess, the system provides evidence.

This is why Retrieval Augmented Generation has become one of the most widely adopted patterns in enterprise AI.

When implemented correctly, it can improve:

Accuracy
Context awareness
Trustworthiness
Freshness of information
Enterprise compliance

The problem is that many teams stop thinking after hearing these benefits.

The Hidden Complexity Nobody Talks About

Most architecture diagrams make RAG look deceptively simple.

The typical diagram includes:

User asks a question
Retrieve documents
Send context to LLM
Generate answer

In reality, production AI systems rarely work this cleanly.

Once RAG enters an existing AI application architecture, several new challenges emerge.

Data Preparation

Your documents are probably messy.

PDFs contain broken formatting.

Knowledge bases have duplicate information.

Internal documentation becomes outdated.

Customer records may exist across multiple systems.

Before retrieval can work effectively, organizations often spend more time cleaning data than building AI features.

Embedding Management

Embeddings sound straightforward until you have millions of documents.

Now you need:

Embedding generation pipelines
Update strategies
Version control
Monitoring
Storage optimization

The retrieval layer becomes a product of its own.

Search Quality

This is where many RAG projects quietly fail.

A language model can only generate answers from what it receives.

If retrieval returns irrelevant documents, the answer quality suffers immediately.

Many teams blame the model when the retrieval layer is actually the bottleneck.

What Most Teams Get Wrong

The biggest mistake I see is treating RAG as a feature rather than infrastructure.

Teams often ask:

"How do we add RAG?"

The better question is:

"How will retrieval fit into our existing architecture?"

There's a massive difference.

Adding Retrieval Augmented Generation affects:

Data pipelines
Security models
Access controls
Storage systems
Monitoring
Cost structures

A chatbot demo can be built in a weekend.

A reliable enterprise AI platform can take months.

The gap between those two realities is where most budgets disappear.

Mistake #1: Building for Scale Too Early

Some organizations design for 100 million documents before validating value with 10,000.

This leads to unnecessary infrastructure spending.

Start small.

Prove usefulness.

Scale later.

Mistake #2: Ignoring Content Quality

Many teams assume more data automatically creates better answers.

In practice, poor documentation creates poor retrieval.

Garbage in.

Garbage out.

RAG doesn't magically fix knowledge management problems.

It exposes them.

Mistake #3: Chasing Perfect Accuracy

Another common trap is endlessly tuning retrieval parameters.

Some teams spend months optimizing retrieval scores while users are perfectly satisfied with simpler implementations.

Perfect systems rarely win.

Useful systems do.

The Cost Side of the Equation

One thing I appreciated in the original GeekyAnts discussion was the attention given to cost considerations rather than treating RAG as a purely technical problem.

Too many AI conversations focus only on capability.

Few discuss economics.

Every RAG architecture introduces additional expenses:

Embedding generation
Vector database storage
Retrieval infrastructure
API usage
Data processing
Maintenance overhead

Organizations often calculate LLM costs while ignoring everything surrounding the model.

Ironically, retrieval infrastructure can sometimes become a larger operational concern than the language model itself.

This is especially true for enterprise AI environments where data volumes grow continuously.

For teams evaluating architecture decisions, the cost discussion deserves as much attention as model selection.

When RAG Is Actually Worth It

Not every AI application needs Retrieval Augmented Generation.

That's an unpopular opinion, but I believe it's true.

RAG is worth the investment when:

Your Information Changes Frequently

Policies, regulations, product catalogs, support documentation, and internal knowledge bases all change regularly.

Retrieval ensures answers remain current.

Hallucinations Carry Business Risk

If incorrect answers could create legal, financial, or operational consequences, retrieval becomes significantly more valuable.

You Need Enterprise Knowledge

Public models cannot access private company information.

RAG provides a practical way to connect proprietary knowledge with language models.

Users Expect Source Attribution

Many enterprise users want evidence behind responses.

Retrieval makes citations and traceability easier to implement.

When You Probably Don't Need RAG

This might be controversial.

But many applications work perfectly well without it.

Examples include:

Creative writing tools
Brainstorming assistants
Marketing content generators
General productivity assistants
Coding helpers for common frameworks

Adding retrieval to these use cases often introduces complexity without meaningful gains.

Not every AI problem requires a vector database.

My Take

I think the AI industry has accidentally turned RAG into the default answer for every problem.

Need AI?

Add RAG.

Need accuracy?

Add RAG.

Need enterprise adoption?

Add RAG.

That's become the standard playbook.

The reality is more nuanced.

RAG architecture is incredibly valuable when it solves a genuine information access problem.

But I've also seen teams build elaborate retrieval systems that produced only marginal improvements.

The most successful AI projects I've observed focus on business outcomes first and architecture second.

They don't start with technology choices.

They start with user needs.

Only then do they decide whether Retrieval Augmented Generation belongs in the stack.

That's a subtle difference, but it's often the difference between a successful AI initiative and an expensive experiment.

For anyone exploring implementation details, I found this breakdown of integration approaches, tooling considerations, and cost factors from GeekyAnts useful background reading on the topic.

Building Production AI Systems Requires More Than Retrieval

One lesson becoming increasingly clear across the industry is that production AI systems require a broader perspective than model selection or retrieval strategy.

Organizations need:

Observability
Governance
Security
Cost management
Feedback loops
Evaluation frameworks

RAG is one component.

Not the entire solution.

The companies seeing the strongest results from enterprise AI aren't necessarily using the most sophisticated architectures.

They're using architectures that align with actual business requirements.

That's a much harder challenge than choosing a vector database.

Conclusion

Retrieval Augmented Generation has earned its place in modern AI application architecture.

But I think many teams approach it backwards.

Instead of asking how to add RAG, ask what problem retrieval is solving.

Instead of chasing architectural complexity, focus on measurable value.

And instead of assuming every AI product needs a retrieval layer, evaluate whether your users truly benefit from one.

RAG can dramatically improve enterprise AI systems.

It can also become an expensive distraction.

The difference usually comes down to architectural discipline rather than technology.

What has your experience been with RAG architecture?

Have you seen meaningful gains in production, or do you think the industry is overusing Retrieval Augmented Generation? I'd love to hear different perspectives in the comments.

AI Prototypes Look Ready, But Are They Enterprise-Ready?"

Raj — Fri, 22 May 2026 07:24:24 +0000

AI prototyping tools have made product development feel incredibly fast.

A founder, developer, or product team can now generate an app interface, workflow, or demo-ready prototype in minutes. That speed is useful, especially when the goal is to validate an idea, create a pitch, or show an early version of a product.

But there is a big difference between something that looks ready and something that is actually ready for enterprise use.

This gap was discussed in an AI ThoughtMakers discussion on SSO, audit logs, and RBAC, where the conversation focused on why AI-generated prototypes often fail to meet enterprise expectations.

The core idea is simple: AI can help generate software quickly, but it cannot automatically generate trust.

And in enterprise software, trust matters more than speed.

A good demo is not the same as a production-ready product

AI-generated prototypes often look impressive.

The UI may be polished. The flow may feel smooth. The product may look convincing during a demo.

But production software is judged differently.

Enterprise customers do not only care about how the product looks. They care about how it behaves when real users, real permissions, real data, and real security risks are involved.

That is where many prototypes start to fall apart.

A prototype becomes a liability when teams treat it as a finished product. For an early-stage demo, a lightweight system may be enough. But for production, the product needs security, scalability, access control, auditability, and a clear architecture.

Without these foundations, the product may impress in a pitch but fail during an enterprise review.

Why SSO is harder than it looks

Single Sign-On sounds simple from the outside.

A user logs in once and gets access to multiple services. But in an enterprise setup, SSO is much more than a login feature.

It connects identity, permissions, sessions, roles, and organizational structure.

Different users may need different levels of access. One employee may belong to multiple teams. A manager may need visibility across departments. A contractor may need limited access. An admin may require deeper control over the system.

This makes SSO deeply connected to the way an organization actually works.

That is why a generic AI-generated authentication module is usually not enough. It may create a working login flow, but enterprise SSO needs context.

It needs to understand how access is granted, how identity providers are used, how sessions are managed, and how permissions change across roles.

Without that context, the implementation may work technically but still fail in practice.

Audit logs are ignored until something goes wrong

Audit logs are one of the most underrated enterprise features.

They are not exciting in a demo. They do not make the UI look better. They are easy to delay when a team is moving fast or trying to reduce scope.

But when something goes wrong, audit logs become critical.

Without audit logs, teams have no reliable way to trace what happened. They may know that an issue occurred, but they may not know who triggered it, when it happened, or what changed before the failure.

That creates a serious problem for debugging, compliance, and accountability.

Audit logs act like a record of truth inside the system. They help teams understand user actions, investigate incidents, and prove what happened during a security or operational issue.

For enterprise software, this is not optional. A customer needs to know that if something breaks, the system can provide evidence instead of assumptions.

RBAC is simple in theory and complex in practice

Role-Based Access Control sounds straightforward.

Create roles. Assign permissions. Give users access based on those roles.

In a small product, this may be manageable. But in a real organization, RBAC can quickly become complicated.

People move between teams. Some users hold multiple responsibilities. Permissions overlap. Certain roles need temporary access. Some users need read-only permissions, while others need full administrative control.

As the number of roles and permissions grows, the number of possible combinations grows with it.

This is where role explosion begins.

A mature access control system does not usually give every user direct custom permissions. Instead, it defines roles carefully so that people can move in and out of responsibilities while the access model stays consistent.

AI can help create a basic structure, but RBAC still needs thoughtful design and expert review.

Access control is too important to treat as generated boilerplate.

The real risk is misplaced confidence

AI tools are not the problem.

They are useful for prototyping, brainstorming, creating early demos, and accelerating development. They help teams move faster from idea to visible product.

The problem starts when teams confuse generated output with production readiness.

An AI-generated application can create confidence before the architecture deserves it. It can look complete while missing the deeper systems that enterprise customers care about.

That creates a new kind of technical debt.

Instead of slowly accumulating messy code over time, teams may start with a fast-generated system that needs major rework once security, scalability, and compliance requirements appear.

In some cases, AI does not remove complexity. It simply hides it until later.

AI should assist security-critical systems, not own them

AI can help with security-related work, but it should not be treated as the final authority.

For systems involving authentication, authorization, audit logs, compliance, and access control, human review is still necessary.

Even traditionally built security systems go through multiple levels of review. AI-generated systems should not skip that process.

The faster AI makes development, the more important review becomes.

Speed is useful only when teams understand what still needs to be validated.

Final thought

AI has made prototyping faster than ever.

That is a huge advantage for builders. But enterprise software is not adopted only because it looks impressive. It is adopted because customers can trust it.

That trust comes from architecture, security, auditability, and accountability.

SSO, audit logs, and RBAC may not be the most exciting features in a demo, but they are often the features that decide whether a product can survive in the real world.

Build fast when speed helps.

But if the goal is to build something that lasts, trust cannot be an afterthought.

Prototype to Production: What Nobody Tells You About Shipping AI in the Real World

Raj — Thu, 14 May 2026 08:41:47 +0000

You've built the demo. It runs clean, the stakeholders are impressed, and someone in the room says "let's ship this."

Then reality hits.

The model starts hallucinating on edge cases. Token costs spiral. Your clean prototype data doesn't look anything like what real users throw at it. The agentic workflow that looked elegant in the notebook turns into an infinite loop in staging.

This is the gap almost no one talks about: the massive, messy distance between a working prototype and a production-grade AI application.

I had a deep conversation with Manav Goyal, Principal Technical Consultant at Geekians, about exactly this , what breaks, what to build differently, and how to think about AI systems that actually hold up under real-world pressure. (You can watch the full discussion (https://www.youtube.com/watch?v=PrIK6Z6TA_I)

Here's what I took away.

The Prototype vs. Production Mindset Shift

The fundamentals are genuinely different between the two phases , and confusing them is where most teams go wrong.

Prototype fundamentals:

Speed of development
Proof of concept
Impressing stakeholders or investors

Production fundamentals:

Security and compliance (GDPR, OWASP LLM Top 10, HIPAA if you're in healthcare)
Reliability at scale , thousands of concurrent users, not just ten
Data quality and diversity, not just clean sample data
LLM Ops: monitoring token consumption, costs, latency
User trust , will people come back tomorrow?

The failure mode Manav describes is teams treating a prototype win as a production green light. It isn't. A prototype proves the idea works once, under ideal conditions. Production means it works under pressure, at scale, across edge cases you didn't anticipate.

Why "Just Plug in an LLM" Doesn't Work

There's a persistent myth that AI is plug-and-play , drop in a model, hand it a long system prompt, and watch it build your application.

That's not how production systems work.

Real agentic workflows involve:

Multiple agents with dedicated responsibilities, not one monolith
Evaluation checkpoints between stages so failures don't cascade
Token budget management (a single drift analysis can hit 1 million tokens , fast)
Proper traces and logs for every internal and external agent call
Handling ambiguity gracefully rather than silently failing

A useful mental model here: instead of one giant prompt, think decomposed tasks with dedicated agents. Each agent owns a clearly defined scope. Each handoff gets validated. You don't just hope the context flows through cleanly , you verify it.

AI Across the Entire SDLC

One of the more interesting shifts happening right now is AI entering every phase of the software development lifecycle, not just the coding phase.

Here's what that looks like in practice:

Ideation & Research: AI-driven market analysis and competitor research, replacing days of manual work
Planning & Estimation: LLM-assisted feature decomposition with effort and cost estimates, grounded in prior project data
Design & Architecture: Spec-driven development , architecture diagrams and TRDs as AI inputs, not afterthoughts
Development:Agents writing code against well-defined specs, with human review checkpoints
QA: Automated evaluation against expected outputs, hallucination checks baked into the definition of done
Deployment: Infrastructure-as-code managed by dedicated deployment agents
Maintenance: Continuous monitoring and drift analysis

The key word across all of these is decomposition. The more precisely you define the task, the better the output. Vague prompts produce vague results. Spec-driven, context-rich inputs produce outputs you can actually ship.

The Challenges Nobody Budgets For

When you're moving from prototype to production, expect to spend real time on things that weren't in the original estimate.

Data Quality

Prototypes run on clean, curated data. Production doesn't. Real users submit messy inputs, edge cases, and data that breaks your pipeline assumptions. You need to think hard about:

Data ingestion frequency and rate limits from third-party APIs
Cleansing and normalization before any processing
How diversity in input data affects your model's behavior

Security

OWASP has a Top 10 for LLM applications now. Prompt injection, data leakage, insecure outputs , these aren't theoretical. If you're in fintech or healthcare, compliance isn't optional; it's table stakes.

User Trust

This one's easy to underestimate. A real example: a dental application that transcribes doctor-patient conversations to generate treatment plans. Impressive prototype. But in production, the audio inputs are unpredictable. If the transcription misses a specific crown type or an anesthesia dosage, the application becomes a liability, not an asset.
The fix was an agent that detects ambiguity in the transcript and asks clarifying questions before finalizing the plan. That gap , from "it usually works" to "it handles what it doesn't know" , is what production-grade means.

Observability: The Bridge Between Developers and the CXO

One of the most practical pieces of advice from this conversation: shared observability is how you align technical and business stakeholders.

Developers care about feasibility and performance. Executives care about ROI and business impact. These aren't incompatible , but you need a shared language to connect them.

That shared language is metrics:

Token consumption per task , directly translates to cost
Agent trace logs , what reasoning path did the agent take, and why?
Evaluation scores , how close is the output to the intended design?
Traditional infra metrics , CPU, DB storage, latency spikes

When both sides can look at the same dashboard and answer "is this worth what we're spending?", the conversation changes from "trust us" to "here's the data."

Developer Roles Aren't Disappearing , They're Evolving

The layoff news is real, and the fear is understandable. But the more accurate framing is that the shape of the developer role is changing, not disappearing.

Developers who thrive in this environment will:

Think like strategic orchestrators, not just coders
Practice *evaluation-driven development *, hallucination checks, ethical inference, and continuous eval inside the definition of done
Use AI tools (Cursor, Claude Code, etc.) with precision , spec-driven inputs, not blind generation
Keep humans in the loop at the right checkpoints, not treat AI as fully autonomous

Blind autopilot coding is a liability. Thoughtful, spec-driven, human-reviewed AI-assisted development is a force multiplier.

Key Takeaways

If you're working on an AI product right now, here's the practical short list:

Prototype proves the idea. Production proves the system. Don't confuse the two.
Decompose your agentic workflows. One prompt to rule them all is a recipe for infinite loops and runaway costs.
Define your evaluation criteria before you build, not after.
Data quality is a production problem, not a data team problem. Budget for it.
Token costs are a business metric. Track them like you track infrastructure spend.
User trust is built through reliability and transparency, not just impressive demos.
Document your specs before you code. Architecture diagrams and TRDs aren't overhead , they're your most reliable AI input.

The teams shipping AI that lasts aren't moving the fastest. They're moving with the most precision.

DEV Community: Raj

Discussion: Is Code Figma More Valuable Than Figma Code?

AI Doesn't Make Great Engineers. It Makes the Gap Between Good and Great Even Bigger.

Coding Is Becoming a Commodity

My Opinion: Architecture Is Becoming More Valuable Than Coding

Junior Engineers Face a Bigger Challenge Than Anyone Else

AI Should Be Your Pair Programmer, Not Your Brain

Companies Leading AI-Native Product Engineering

The AI Tools Don't Matter as Much as Everyone Thinks

Final Thoughts

Top Companies Driving AI-Powered Digital Banking Transformation in 2026

Why Payments and Digital Wallets Are Becoming the Most Important Software Products in Finance

Payments Have Become a Product, Not a Feature

Why Digital Wallets Are Reshaping Financial Services

Building Payments Is Far More Difficult Than Most Teams Realize

Companies Building the Future of Payments and Digital Wallets

1. Stripe

2. Block (formerly Square)

3. PayPal

4. Adyen

5. GeekyAnts

6. EPAM Systems

7. Globant

8. Thoughtworks

My Opinion: Payments Are the Most Strategic Layer of Modern Finance

What actually makes a fintech company “top-performing” today?

Why Most Teams Overcomplicate RAG (And End Up Burning Money)

The Real Problem RAG Solves

The Hidden Complexity Nobody Talks About

Data Preparation

Embedding Management

Search Quality

What Most Teams Get Wrong

Mistake #1: Building for Scale Too Early

Mistake #2: Ignoring Content Quality

Mistake #3: Chasing Perfect Accuracy

The Cost Side of the Equation

When RAG Is Actually Worth It

Your Information Changes Frequently

Hallucinations Carry Business Risk

You Need Enterprise Knowledge

Users Expect Source Attribution

When You Probably Don't Need RAG

My Take

Building Production AI Systems Requires More Than Retrieval

Conclusion

Further Reading

AI Prototypes Look Ready, But Are They Enterprise-Ready?"

A good demo is not the same as a production-ready product

Why SSO is harder than it looks

Audit logs are ignored until something goes wrong

RBAC is simple in theory and complex in practice

The real risk is misplaced confidence

AI should assist security-critical systems, not own them

Final thought

Prototype to Production: What Nobody Tells You About Shipping AI in the Real World

The Prototype vs. Production Mindset Shift

Why "Just Plug in an LLM" Doesn't Work

AI Across the Entire SDLC

The Challenges Nobody Budgets For

Observability: The Bridge Between Developers and the CXO

Developer Roles Aren't Disappearing , They're Evolving

Key Takeaways