DEV Community: divya bathoju

Beyond the AI Hype: Navigating Migration, Compression, and the Future of Engineering

divya bathoju — Mon, 19 Oct 2026 23:26:23 +0000

Over the past year, my daily workflow as a developer has fundamentally shifted. I transitioned from writing code manually to prompting AI, developing dedicated toolkit to refine prompt quality, and integrating AI into every stage of the software development lifecycle.

Working like this every day has given me a much more grounded perspective on where software engineering is actually heading. I don't buy the narrative that AI is going to kill coding or make software engineers obsolete overnight. What I am seeing instead is a clear structural shift: an intensive Migration Era followed by a gradual Compression of the Core Engineering Team.

Here is what that looks like from the ground level. I'd love to hear how this aligns with what you're seeing in your own teams.

Phase 1: The Migration Era is a Dual-Track Reality

Before engineering teams can get smaller or move faster, most companies have to undergo a massive wave of technical cleanup and restructuring. This migration isn't headline-grabbing work, but it's happening along two parallel tracks right now:

Track 1: System Modernization (Cleaning Up Technical Debt): We are using automated scripts and AI tools to untangle legacy monolithic code, build reliable test suites, and migrate outdated dependencies to managed infrastructure. The goal here is simple: reduce the maintenance tax required just to keep existing systems running.
Track 2: Data Restructuring (Preparing for AI Capabilities): You can't deploy reliable AI features or autonomous agents without structured, accessible data. Most organizations are realizing that to build anything meaningful, they have to overhaul their internal data pipelines, consolidate APIs, and clean up domain models first.

The major risk during this phase is rushing in without a strategy. If teams just use LLMs to spit out syntax faster without fixing their underlying architecture, they end up creating a messy hybrid state.
This creates immense cognitive debt, resulting in sprawling, unmaintainable codebases that no single developer fully understands, paired with fragile data schemas and endless code review bottlenecks. The teams making real progress are the ones taking time to build clean interfaces and unified data foundations that AI assistants can safely work with.

Phase 2: Outsourced Infrastructure and Team Compression

Critics will rightly point out that it takes a village to run software. Maintaining server stability, monitoring uptime, patching endless security vulnerabilities, and handling strict enterprise compliance (like GDPR or data sovereignty) is a relentless, full-time job.

That’s true, but modern engineering teams rarely build or maintain that heavy machinery in-house anymore. They offload it:

Infrastructure overhead is pushed to fully managed platforms like AWS, Cloudflare, or Vercel.
Complex business domains are delegated to specialized APIs like Stripe for payments or Auth0/Clerk for identity management.
Automated pipelines and monitoring bots flag, test, and patch security dependencies before engineers even open a ticket.

Because so much underlying operational weight is handled by third-party platforms and automation, internal engineering team structures are naturally changing.

The Realistic Future: Compression, Not Disappearance

There’s plenty of hype right now about solo developers building billion-dollar companies or small teams replacing enterprise giants overnight. Practically speaking, that’s an edge case.
Building software at scale still involves navigating human problems, localized laws, user research, customer support, and strategic trade-offs. You can’t comfortably run a scaling enterprise product with two people without burning out.
Real businesses have to solve multiple, complex, deeply human problems at once (from localized legal compliance to nuanced user psychology). You cannot run a sprawling enterprise system with two overworked founders without facing catastrophic burnout.

Instead, the true shift will be Team Compression.

What is actually happening is Team Compression. Engineering pods are becoming leaner and more concentrated. Instead of needing ten developers to build and maintain a core service, a focused team of two or three senior engineers can achieve the same output by orchestrating AI tools and managed services. Organizations that once needed a hundred engineers to handle coordination and maintenance can operate far more efficiently with twenty.

The New Developer Skillset

As AI tools handle routine code generation, pure syntax writing is no longer the main bottleneck. Value has shifted heavily toward system architecture, data design, product intuition, and domain knowledge.

The most impactful engineers will be those who know how to connect systems securely, organize clean data pipelines, and translate real business problems into working software.

Over to You: Agree or Disagree?

This reflects what I've experienced firsthand while building alongside AI tooling over the last year.

Do you agree that data restructuring and technical debt cleanup are the biggest roadblocks right now, and that solving them will naturally lead to smaller teams?
Or do you think the ongoing maintenance and debugging burden of AI-assisted code will force teams to stay large just to manage the complexity?

I'd love to hear your thoughts in the comments.

Add AI to your existing web APIs using Semantic Kernel

divya bathoju — Tue, 13 May 2025 11:52:32 +0000

Are you looking to integrate artificial intelligence into your .NET APIs without a complete overhaul? Consider Semantic Kernel, a tool that allows smooth AI prompt integration with your application logic, adding intelligence and automation easily.

Semantic Kernel is an open-source AI orchestration library from Microsoft. It is model-agnostic, allowing you to choose your preferred models, whether self-hosted or third-party. It includes features like observability and strong security measures, such as filters to protect against prompt injection attacks, enabling you to build reliable, enterprise-grade applications effortlessly.
In this post, you'll learn how to:

Set up Semantic Kernel in ASP.NET Core Web API
Configure the model for the application
Describe existing code to the AI Model
Add a simple prompt endpoint that accepts user requests
Leverage filters to implement logging for tracking the end-to-end request trail.

Step-by-step instructions

Step 1: Install Semantic Kernel

Add nuget package in your existing web API project

dotnet add package Microsoft.SemanticKernel

Step 2: Add Semantic Kernel to your web application builder

 public static void Main(string[] args)
 {
     var builder = WebApplication.CreateBuilder(args);

     // ... 
     // Add Kernel
     builder.Services.AddKernel();
}

Step 3: Add model ( below code uses local model running using Ollama, if you are using 3rd party, set modelid and apikey, you don't need endpoint property)

// Add LLM 
builder.Services.AddOpenAIChatCompletion(
   modelId: "llama3.2:latest",
   endpoint: new Uri("http://localhost:11434/v1"),
   apiKey: "");

Step 4: Describe your existing code to AI model using function descriptors. Ensure the description matches the intent of the method and this is key for model to identify the right functions to call.
Because the LLMs are predominantly trained in python, use snake_case format for kernel function names and parameters.

Step 5: Register the above class as Kernel Plugin. You can register even HttpClient (Let's say your API is calling another API to fulfill request) as plugins.

// Add your existing services as Kernel plugins
builder.Services.AddTransient(serviceProvider =>
{
    Kernel k = new(serviceProvider);
    var productRepository = serviceProvider.GetRequiredService<IProductService>();
    k.Plugins.AddFromObject(productRepository);
    return k;
});

Step 6: Add a sample Prompt Endpoint and Invoke Kernel with the prompt

 public class PromptController : Controller
    {
        private readonly Kernel _kernel;
        public PromptController(Kernel kernel)
        {
            _kernel = kernel;
        }
        [HttpGet]
        public async Task<IActionResult> HandlePromptAsync(string prompt)
        {
            OpenAIPromptExecutionSettings settings = new() { ToolCallBehavior = ToolCallBehavior.AutoInvokeKernelFunctions};
            var result = await _kernel.InvokePromptAsync<string>(prompt, new(settings));
            return Ok(result);
        }
    }

Step 7: Add FunctionFilter to see the request trail

public class FunctionFilter : IAutoFunctionInvocationFilter
    {
        public async Task OnAutoFunctionInvocationAsync(AutoFunctionInvocationContext context, Func<AutoFunctionInvocationContext, Task> next)
        {
            Console.WriteLine($"{nameof(FunctionFilter)}.FunctionInvoking - {context.Function.PluginName}.{context.Function.Name}");
            await next(context);
            Console.WriteLine($"{nameof(FunctionFilter)}.FunctionInvoked - {context.Function.PluginName}.{context.Function.Name}");
        }
    }

Step 8: Register the FunctionInvocationFilter

 builder.Services.AddSingleton<IAutoFunctionInvocationFilter, FunctionFilter>();

Step 9: Let's test the endpoint (If you are using local model, make sure its up and running)
Prompt provided (create a product tablecloth worth 100$) and response is 200, product is created with name tablecloth and price is set to 100.

Here is the request audit trail.

Let's try retrieving the product

and request trail

Final Thoughts

That’s it! You’ve now extended your API with AI capabilities using Semantic Kernel. While AI can unlock powerful capabilities, it's important to remember that not every product needs AI. Use tools like Semantic Kernel when they genuinely help solve a customer problem or enhance the user experience. Start with the problem, not the technology—and let AI be a solution where it makes sense, not just a trend to follow.