DEV Community: Aswani Nayak

From Prompting to Production: A Practical Framework for AI-Assisted Software Development

Aswani Nayak — Wed, 22 Jul 2026 16:06:22 +0000

How structured workflows, context engineering, and human oversight can transform AI from a coding assistant into a true engineering partner.

Introduction

Generative AI is rapidly changing how software is built. While many development teams have experimented with AI-powered coding tools, the real challenge is not generating code—it's creating a repeatable process that produces reliable, high-quality outcomes.
Recently, we conducted a hands-on workshop to explore how AI can support the complete software development lifecycle. Rather than using toy examples, the session focused on solving a real business problem while applying a structured AI-assisted development workflow.
The result was more than just working software. We uncovered a practical framework that helps engineers collaborate effectively with AI agents, improve productivity, and maintain engineering quality.

The Importance of Preparation

One of the key messages before the workshop was simple:

Don't start with code. Start with understanding.

Developers were encouraged to review business requirements in advance and become familiar with the problem domain before engaging coding agents.
The goal was not simply to generate code faster, but to:
• Understand the business problem
• Validate AI-generated outputs
• Review implementation plans critically
• Verify test cases before implementation
The workshop reinforced a crucial principle:

AI can accelerate development, but humans remain responsible for understanding the business intent.

The Shift from Prompt Engineering to Context Engineering

Many discussions about AI focus on writing the perfect prompt.
The workshop highlighted something more important:
Context engineering.
The best outcomes occurred when engineers supplied:
• Business objectives
• Functional requirements
• Acceptance criteria
• System context
• Integration dependencies
• Architectural constraints
• Source-of-truth considerations
Instead of immediately asking an AI agent to generate code, the team first provided comprehensive context and required the agent to fully understand the problem.
For example:

"I want to create a new Spring Boot application for a sales platform. Review the requirements, understand the acceptance criteria, and grill me on the requirements before creating an implementation plan."

The business requirement explained that sellers needed a streamlined way to serve customers while relying on existing systems as the source of truth and avoiding unnecessary data duplication across platforms.
Providing this level of context dramatically improved the quality of AI-generated plans, test cases, and implementation recommendations.

The "Grill Me" Approach

One of the most valuable concepts introduced during the workshop was the Grill Me technique.
Rather than immediately proposing a solution, the AI agent is instructed to challenge assumptions and ask follow-up questions until it understands the requirements thoroughly.
This transforms the agent from a code generator into a business analyst.
Instead of guessing, the AI asks questions such as:
• What business outcome are we trying to achieve?
• What systems currently own the data?
• What are the integration constraints?
• What are the edge cases?
• What constitutes success?
The objective is to eliminate ambiguity before planning or implementation begins.
This often uncovers gaps in requirements long before development starts.

A Structured AI Development Workflow

The workshop followed a repeatable workflow designed to maximize AI effectiveness while preserving engineering discipline.

Step 1: Requirement Discovery

Provide the business requirements to the AI agent and ask it to fully understand the request before proposing a solution.
The agent should review the available context and ask clarifying questions until requirements are well understood.
Outcome: Clear understanding of the problem.

Step 2: Implementation Planning

Once requirements are understood, the AI generates:
• Solution architecture
• Technical approach
• Task breakdown
• Risks and assumptions
Outcome: An actionable implementation plan.

Step 3: Human Review

Developers review the proposed plan and challenge assumptions.
This is one of the most important phases in the process.
The objective is not to approve the plan blindly but to verify:
• Architectural decisions
• Business alignment
• Missing requirements
• Technical feasibility
Outcome: A validated implementation strategy.

Step 4: Test-Driven Development

Before writing code, the AI generates test cases.
A structured TDD approach encourages engineers to define expected system behavior before implementation begins.
Benefits include:
• Better requirement validation
• Improved quality
• Higher confidence in outcomes
• Earlier detection of requirement gaps
Outcome: Comprehensive test coverage aligned to business needs.

Step 5: Review Test Cases

Developers review generated tests to ensure:
• Requirements are fully represented
• Edge cases are covered
• Acceptance criteria are addressed
Strong test cases frequently reveal requirement gaps before implementation starts.
Outcome: Reliable validation criteria.

Step 6: Code Implementation

After requirements, plans, and tests have been validated, the AI generates implementation code.
Because the earlier phases established strong guardrails, implementation quality improves significantly.
Outcome: Faster and more accurate development.

Step 7: Validation and Refinement

AI-generated code should never be considered production-ready by default.
Engineers still perform:
• Code reviews
• Functional validation
• Performance verification
• Security checks
• Refinement and optimization
Outcome: Production-quality software.

Why This Approach Works

Several important lessons emerged from the workshop.
Requirements Quality Drives AI Quality
The quality of the output is directly related to the quality of the requirements provided.
Clear business requirements consistently produce:
• Better implementation plans
• Better test coverage
• Better code quality

Human Oversight Remains Critical

AI can accelerate analysis, planning, testing, and coding.
It cannot replace engineering judgment.

Developers remain responsible for:
• Understanding business intent
• Challenging assumptions
• Evaluating architecture
• Ensuring quality

TDD Complements AI Extremely Well

Generating tests before implementation creates a powerful partnership between developers and AI agents.
Tests provide structure, define expectations, and reduce ambiguity.
The combination of AI-generated tests and human review proved particularly effective.

Process Matters More Than the Model

One of the most surprising lessons was that success depended less on the specific AI model being used and more on the workflow surrounding it.
Teams often focus on finding the "best" model.
In reality, a disciplined process consistently delivered better results than relying on model capabilities alone.

The Evolving Role of Developers

Perhaps the most significant takeaway is that software engineering is evolving.
Developers are spending less time writing repetitive code and more time:
• Understanding business problems
• Evaluating solutions
• Reviewing AI-generated outputs
• Designing systems
• Defining quality standards
• Making architectural decisions
The most valuable engineering skill is no longer typing code quickly.
It is providing the right context, asking the right questions, and validating the right outcomes.

Conclusion

The future of software development is not about replacing engineers with AI.
It is about creating an effective partnership between human expertise and AI capabilities.
The workshop demonstrated that successful AI adoption begins long before code generation. It starts with understanding requirements, providing rich context, challenging assumptions, reviewing plans, validating tests, and maintaining ownership of quality throughout the development lifecycle.
When combined with a disciplined workflow, AI becomes more than a productivity tool—it becomes a force multiplier for engineering teams.

Enabling CSRF in a JWT-Based React + Spring Boot Application (Enterprise-Ready Approach)

Aswani Nayak — Wed, 27 May 2026 13:52:27 +0000

Modern applications often use:
• React SPA (Single Page Application)
• Spring Boot backend
• JWT-based authentication
• Stateless REST APIs
In this architecture, it’s common to disable CSRF:
Code
.csrf(AbstractHttpConfigurer::disable)
However, many enterprise security teams and tools (e.g., GitHub CodeQL) flag this as a high-severity issue.
This blog explains:
• ✅ Why CSRF is flagged
• ✅ Whether JWT APIs need CSRF
• ✅ How to enable CSRF without breaking your SPA
• ✅ A production-ready implementation

1️⃣ Understanding the Problem
What is CSRF?
CSRF (Cross-Site Request Forgery) is an attack where a malicious website tricks a browser into making an authenticated request to another site.
CSRF attacks rely on:
• Automatic cookie sending by the browser
• Session-based authentication
Spring Security enables CSRF by default for this reason.

Why JWT APIs Typically Disable CSRF
In a JWT-based system:
• Authentication is done via:
• Authorization: Bearer
• Browsers do NOT automatically attach Authorization headers.
• No session cookies are involved.
• The API is stateless.
Therefore, CSRF protection is not strictly required.
However...

Why Security Teams Still Want It Enabled
Enterprise AppSec teams often require:
• Defense-in-depth
• Uniform policy enforcement
• Future-proof protection (in case cookies are introduced later)
• Clean security scans without exceptions
Instead of disabling CSRF, we can implement it correctly for SPA.

2️⃣ Enterprise-Ready Solution
We will:
• ✅ Keep JWT authentication
• ✅ Keep backend stateless
• ✅ Enable CSRF
• ✅ Make it work with React SPA
• ✅ Pass security review
The key is:
Code
CookieCsrfTokenRepository

3️⃣ Spring Boot Implementation
✅ Step 1: Security Configuration
Code

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    private final JwtAuthenticationFilter jwtAuthenticationFilter;

    public SecurityConfig(JwtAuthenticationFilter jwtAuthenticationFilter) {
        this.jwtAuthenticationFilter = jwtAuthenticationFilter;
    }

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {

        http
            // ✅ Enable CSRF with Cookie repository (SPA-friendly)
            .csrf(csrf -> csrf
                .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
            )

            // ✅ Keep application stateless
            .sessionManagement(session ->
                session.sessionCreationPolicy(SessionCreationPolicy.STATELESS)
            )

            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/auth/**").permitAll()
                .anyRequest().authenticated()
            )

            // ✅ Add JWT filter
            .addFilterBefore(jwtAuthenticationFilter,
                    UsernamePasswordAuthenticationFilter.class);

        return http.build();
    }
}

✅ What This Does
Spring Security will:

Generate a CSRF token
Send it in a cookie named: XSRF-TOKEN
Expect the frontend to send it back in header: X-XSRF-TOKEN This pattern is SPA-friendly and secure.

4️⃣ React Implementation
✅ Step 1: Enable Credentials
When using cookies, you must enable credentials:
Code

const api = axios.create({
  baseURL: "http://localhost:8080",
  withCredentials: true
});

✅ Step 2: Read CSRF Cookie
Helper function:
Code

function getCookie(name) {
  const value = `; ${document.cookie}`;
  const parts = value.split(`; ${name}=`);
  if (parts.length === 2) return parts.pop().split(';').shift();
}

✅ Step 3: Axios Interceptor
Code

api.interceptors.request.use((config) => {

  const jwt = localStorage.getItem("jwt");
  const csrfToken = getCookie("XSRF-TOKEN");

  if (jwt) {
    config.headers.Authorization = `Bearer ${jwt}`;
  }

  if (csrfToken) {
    config.headers["X-XSRF-TOKEN"] = csrfToken;
  }

  return config;
});

Now every request sends:
• ✅ JWT token
• ✅ CSRF token

5️⃣ CORS Configuration (Critical)
When using cookies, you must allow credentials.
Code

@Bean
public CorsConfigurationSource corsConfigurationSource() {
    CorsConfiguration configuration = new CorsConfiguration();
    configuration.setAllowedOrigins(List.of("http://localhost:3000"));
    configuration.setAllowedMethods(List.of("GET", "POST", "PUT", "DELETE"));
    configuration.setAllowedHeaders(
        List.of("Authorization", "Content-Type", "X-XSRF-TOKEN")
    );
    configuration.setAllowCredentials(true);

    UrlBasedCorsConfigurationSource source =
            new UrlBasedCorsConfigurationSource();
    source.registerCorsConfiguration("/**", configuration);
    return source;
}

And enable CORS:
Code
http.cors(Customizer.withDefaults());

6️⃣ Request Flow Explained
✅ Initial Request
• Backend generates CSRF token
• Sends XSRF-TOKEN cookie
✅ API Call
React sends:
Authorization: Bearer
X-XSRF-TOKEN:
✅ Spring Validates
• JWT signature
• CSRF token match
If both valid → request succeeds.

7️⃣ Architecture Summary

8️⃣ Why This Is a Strong Design
Even though JWT Authorization header authentication does not require CSRF, enabling it provides:
• Defense-in-depth
• Protection against future cookie-based changes
• Compliance with security standards
• Cleaner audit results
This approach balances:
✅ Security
✅ Architecture purity
✅ Enterprise compliance

9️⃣ Final Thoughts
If you are building:
• React SPA
• Spring Boot backend
• JWT authentication
And your security team requires CSRF to be enabled:
✅ Use CookieCsrfTokenRepository
✅ Send CSRF token via header
✅ Keep the application stateless
This gives you:
• Modern architecture
• Strong security posture
• Enterprise-ready implementation

Storing Personal Information in React: sessionStorage vs Context API

Aswani Nayak — Mon, 18 May 2026 02:25:35 +0000

When building React applications, developers often need to handle personal information such as names, emails, profile data, or authentication details.
A common question arises:
Should I store personal information in sessionStorage or use React’s Context API?
The answer depends heavily on security, persistence needs, and application design. In this post, we’ll break down the differences, risks, and best practices.

Understanding the Two Options
1️⃣ What Is sessionStorage?
sessionStorage is a browser-based storage mechanism that:
• Stores data per tab
• Persists across page refreshes
• Clears when the tab is closed
• Is accessible via JavaScript
Example:
Code

// Store data
sessionStorage.setItem("userEmail", "user@example.com");

// Retrieve data
const email = sessionStorage.getItem("userEmail");

2️⃣ What Is React Context API?
The Context API is a React feature that allows you to:
• Share state across components
• Store data in memory
• Avoid prop drilling
• Reset data on page refresh
Example:
Code

import { createContext, useContext, useState } from "react";

const UserContext = createContext();

export const UserProvider = ({ children }) => {
  const [user, setUser] = useState(null);

  return (
    <UserContext.Provider value={{ user, setUser }}>
      {children}
    </UserContext.Provider>
  );
};

export const useUser = () => useContext(UserContext);

Key Differences

Security Considerations (Critical for Personal Info)
When storing personal information (PII), security should be your top priority.
🔴 Risks of Using sessionStorage
• Accessible via browser DevTools
• Accessible to any script running on the page
• Vulnerable to Cross-Site Scripting (XSS)
• Persists after refresh (increasing exposure window)
If your app suffers from an XSS vulnerability, malicious code could easily run:
Code
sessionStorage.getItem("userSSN");
That’s a serious risk.

🟢 Why Context API Is Safer
Context data:
• Lives only in memory
• Disappears on refresh
• Is scoped within your React app
• Is not automatically accessible globally
However, note:
Context is still vulnerable to XSS if your app is compromised.
No client-side storage is 100% secure.

When Should You Use Each?
✅ Use Context API When:
• Handling sensitive personal information
• Data does not need to survive page refresh
• You want better encapsulation
• Managing user session state
Examples:
• User profile details
• Temporary form data
• Authenticated user state

✅ Use sessionStorage When:
• You need data to persist across refresh
• The data is low sensitivity
• UX depends on temporary persistence
Examples:
• Wizard step progress
• Non-sensitive UI preferences
• Temporary search filters

What You Should NEVER Store in sessionStorage
Avoid storing:
• Passwords
• Social Security Numbers
• Credit card numbers
• Medical data
• Raw authentication tokens
• Sensitive PII
If the data would be catastrophic if exposed — don’t store it client-side.

The Best Practice Architecture
For handling personal information securely in modern React apps:
✅ Recommended Approach
• Store authentication tokens in HTTP-only secure cookies
• Store user profile data in React Context (memory)
• Keep highly sensitive data on the backend only
Architecture flow:
Backend
↓
HTTP-only cookie (auth token)
↓
React Context (user state in memory)
Why this works:
• HTTP-only cookies cannot be accessed via JavaScript
• Context keeps sensitive UI data ephemeral
• Exposure window is minimized

Final Recommendation
If you're choosing between sessionStorage and Context API for personal information:
✅ Use React Context for sensitive data
⚠️ Use sessionStorage only for low-risk persistence needs
And remember:
The most secure data is the data you never store on the client.