DEV Community: Jasen

AI-assisted development in 2025: the problem is no longer the code

Jasen — Wed, 17 Dec 2025 17:14:56 +0000

AI coding assistants are no longer experimental — they've quietly become part of everyday development. Copilot, Claude, Cursor, agent-based workflows — for many teams this is now just the default way of working.

For a long time, I didn't fully buy into the hype.

I was skeptical. I reviewed almost every line AI produced, verified edge cases, and double-checked logic. Most of the time, AI felt like a very confident junior developer: fast, enthusiastic, but prone to repetition, unnecessary abstractions, and bloated code. No matter which model I tried, the pattern was similar — code that looked ok, but required careful cleanup and verification.

As for me, reading "mostly correct" AI-generated code is cognitively harder than writing it yourself. This isn't just a subjective feeling. A 2025 industry study reported by Reuters found that AI tools sometimes slow down experienced developers, because time saved during generation is lost during review and correction.

Over time, however, something changed — not only in the tools, but also in me.

I started relying more on agents. If the code worked, I stopped checking every single line. Not consciously, not intentionally — it just happened. Only later did I realize that this shift is not unique to me.

Recent research describes this behavior as automation bias — the tendency to trust automated systems even when they are wrong. What's counter-intuitive is that studies show this effect is often stronger in experienced developers than in juniors. Once earlier AI suggestions appear correct, developers become significantly more likely to accept subsequent ones without deep scrutiny.

That finding didn't feel abstract. It explained my own behavior uncomfortably well.

This isn't about losing language knowledge or forgetting syntax. Research on human-AI interaction in development environments points to a deeper issue. A 2025 systematic literature review analyzing 89 peer-reviewed studies shows recurring patterns: reduced independent problem formulation, weaker mental models of systems, and a gradual outsourcing of reasoning to tools.

Developers still know how to implement things — but increasingly rely on AI to decide what to build and why.

From my perspective, this directly translates into growing technical debt. Code is merged without being fully understood. Security and reliability gaps slip through. Architectural understanding becomes shallower over time — especially when AI output "looks good enough".

What worries me most, though, is not the tooling itself, but a cultural shift I'm already hearing in conversations.

"Well, the AI generated it."

Using AI as an explanation — or worse, as a justification — for gaps in understanding or code quality feels dangerous. I don't want to become the engineer who hides behind tools instead of taking responsibility.

Yes, even this article is written with the help of AI tools. And that's fine. We should use every capability available to us. But using powerful tools doesn’t remove the need for understanding.

What I'm arguing for — first and foremost for myself — is mindful development. Approaching code with awareness, not just efficiency.

To overcome it, now I force myself not to commit anything I don't understand. I make myself review the code at least diagonally and leave TODO notes wherever I notice a gap that I can't fix right away. Over time, this has become harder and harder. On older, complex projects that I wrote myself before the era of AI agents, I don't use AI at all — not even to fix small bugs. The benefit there is minimal: I know the codebase, and it's faster for me to find and adjust the issue myself than to write a prompt and wait for a response.

My mantra for 2026: strong engineers will be defined not by how much AI they use, but by their ability to know when not to use it.

References

How to understand Dependency Injection?

Jasen — Wed, 21 May 2025 21:58:43 +0000

Dependency Injection (DI) is a design pattern that manages dependencies by providing (injecting) the required objects (dependencies) to a class from the outside, instead of the class creating them internally.

First, let’s briefly dive into the history.

In 1994, the GoF in their book "Design Patterns: Elements of Reusable Object-Oriented Software" introduced the principle of "Inversion of Control", although they did not call it Dependency Injection, but they defined the principle that an object should not manage its own dependencies, but instead obtain them from outside.
In early 2004, Martin Fowler systematized the idea of DI, presenting it as an implementation of IoC.
In 2004, Spring brought the concept of DI to the Java world. Spring was the first framework to implement DI as a container.

So, why was it necessary?

It's just because DI solves problems. Let's find it out on NestJS.

1. Memory efficiency
Nest.js creates each dependency only once (if using a singleton), and it can be reused across the application. For example:

class Engine {}
class Car {
  constructor(private engine: Engine) {}
}

@Module({
  providers: [Engine, Car],
})
export class AppModule {}

Here, Engine is created only once, even if Car is used in multiple places.

2. Ease of testing
You can easily mock dependencies for testing:

const mockEngine = { start: jest.fn() };
const car = new Car(mockEngine as Engine);

3. Scalability
Instead of tightly coupled objects, you can easily add or replace dependencies in one place.

If this concept still feels challenging, let’s simplify it.

Imagine a chef who needs ingredients. Without DI, the chef grows the vegetables, raises the chickens, and milks the cows. It’s chaos, they’re exhausted, and your dinner is late.

With DI, the chef gets ingredients from a fancy supermarket. They only need to say, "I need chicken and vegetables," and it’s delivered fresh and ready to cook.

In this case, ingredients (Dependencies):

import { Injectable } from '@nestjs/common';

@Injectable()
export class Vegetables {
  get() {
    return 'Fresh vegetables';
  }
}

@Injectable()
export class Chicken {
  get() {
    return 'Organic chicken';
  }
}

Chef (Service):

import { Injectable } from '@nestjs/common';
import { Vegetables } from './vegetables';
import { Chicken } from './chicken';

@Injectable()
export class Chef {
  constructor(private vegetables: Vegetables, private chicken: Chicken) {}

  cookDish(): string {
    const veggies = this.vegetables.get();
    const meat = this.chicken.get();
    return `Cooked dish with ${veggies} and ${meat}`;
  }
}

Restaurant (Controller):

import { Controller, Get } from '@nestjs/common';
import { Chef } from './chef';

@Controller('restaurant')
export class RestaurantController {
  constructor(private chef: Chef) {}

  @Get('order')
  takeOrder(): string {
    return this.chef.cookDish();
  }
}

Module:

import { Module } from '@nestjs/common';
import { Vegetables } from './vegetables';
import { Chicken } from './chicken';
import { Chef } from './chef';
import { RestaurantController } from './restaurant.controller';

@Module({
  providers: [Vegetables, Chicken, Chef],
  controllers: [RestaurantController],
})
export class RestaurantModule {}

What happens?

Client request: User sends a GET request to /restaurant/order.
Controller: RestaurantController receives the request and calls the cookDish() method in Chef.
Service: Chef requests the ingredients (Vegetables and Chicken) via DI.
DI container: NestJS creates instances of Vegetables and Chicken and passes them to Chef.
Result: The string returned is: Cooked dish with Fresh vegetables and Organic chicken.

Conclusion

Dependency Injection is the foundation for creating a non-obvious, scalable, and testable architecture. By using DI, you can spend less time managing dependencies and more time solving business problems.

AI did the heavy lifting by injecting code at my request, while I discovered the recipe, cooked the visuals, and added some extra spice to the writing.