DEV Community: Sanket Bhor

GitHub Copilot dropped flat pricing on June 1st. Now it's usage-based — AI credits, Actions minutes, all metered. Solo devs won't notice. Teams with heavy PR automation? Audit your usage before the bill does it for you.

Sanket Bhor — Sun, 07 Jun 2026 02:10:00 +0000

You're Not Paying for Code Generation. You're Paying for Context

Sanket Bhor — Wed, 03 Jun 2026 15:32:08 +0000

The hidden cost of AI isn't generating code. It's understanding your codebase.

For a long time, I assumed AI coding tools became expensive because they generated a lot of code. These tools can produce components, tests, SQL queries, documentation, and sometimes entire features on demand. If costs were climbing, the output volume must be the reason.

The more I used these tools, the more I realized I was measuring the wrong thing. The expensive part isn't writing code. The expensive part is understanding what code should be written — and that work is mostly invisible. That realization changed how I think about AI-assisted development entirely.

Two Prompts, Two Very Different Problems

Consider these two requests: "Create a utility function that formats dates" and "Review this feature and suggest improvements." At first glance, both look ordinary. Both might even produce short answers. But they require completely different levels of understanding.

The first is narrow and well-defined. The AI needs very little information before it can produce a useful answer. The second is open-ended. Before suggesting a single improvement, the AI may need to read multiple files, understand dependencies, follow existing patterns, compare implementations, and build a mental model of why the feature exists at all.

The output might still be small. The work required to reach it is not.

Why Agent Workflows Feel Different From Autocomplete

This became much clearer when I started using AI agents. Traditional autocomplete is predictive — you type, the AI guesses what comes next. It's fast, cheap, and deliberately context-light.

Agents behave differently. When you ask one to improve a feature or review a workflow, it doesn't immediately start generating code. It starts reading. It follows imports, finds related files, and tries to understand the system before touching it. That is exactly what makes agent workflows feel slower and more resource-intensive than autocomplete: they are spending effort on understanding first.

This is also where the economics become visible. In many agent workflows, the model may consume far more input tokens understanding a codebase than output tokens generating recommendations. The imbalance can be surprisingly large. You're not paying for the answer. You're paying for everything the model had to read before it could write one.

This shows up in concrete ways: repository-wide indexing, codebase context pins, and agentic terminal executions all consume large amounts of context before touching the first generated line.

The Log File Trap

Debugging is where this pattern becomes most visible. A build fails, tests start breaking, a deployment goes sideways — and the natural reaction is to paste everything into the AI and ask what's wrong. I've done it myself: hundreds of lines of logs, stack traces, terminal output, configuration snippets, all dumped in at once.

Most of the time, the relevant information is buried somewhere in the middle. The AI processes all of it anyway. A focused, trimmed stack trace often produces the same answer as a full log dump. The difference is purely in how much context the AI had to wade through to reach it.

The lesson isn't to use AI less. It's to be more deliberate about what information you're providing.

What Changed for Me

Once I started thinking about context rather than code generation, my prompts changed. Instead of "Review this feature," I started asking "Review the authentication logic in these two files." Instead of "Refactor this module," I asked "Simplify this service without changing the public API." Instead of sharing an entire build log, I shared the relevant section.

The clearest example was a three-file authentication refactor where a vague prompt returned generic suggestions about error handling, null checks, and naming — the kind of advice that sounds useful without really changing much. A scoped prompt, on the other hand, immediately surfaced a session invalidation edge case I hadn't considered. It pushed the conversation from cleanup to correctness.

Same codebase. Same AI. Different input, different depth of answer.

The quality of the answers rarely dropped — in many cases it improved. Better prompts weren't just helping the AI. They were forcing me to think more clearly about the problem I was trying to solve.

Final Thoughts

Most discussions about AI costs focus on output: how much code was generated, how many requests were made. Those are easy things to measure. The more important question is usually hidden — how much did the AI need to understand before it could answer?

The goal isn't to eliminate context. The goal is to eliminate unnecessary context. That distinction matters more than it sounds. In most cases, we're not paying for code generation. We're paying for understanding.

The code is usually the easy part. Understanding the problem has always been where the real work happens.

Have you noticed similar patterns while using AI coding assistants? I'd love to hear how your workflows have changed.

I write about frontend problems from real projects — follow if that's useful.

If this helped, drop a ❤️ — it helps with visibility.

Connect with me:

LinkedIn: Sanket Bhor
Website: sanketbhor.dev

loadComponent vs loadChildren in Angular 19: Choosing the Right Lazy-Loading Boundary

Sanket Bhor — Sun, 31 May 2026 17:55:58 +0000

There's a pattern I've been seeing more frequently across Angular codebases since standalone components became mainstream.

A team migrates away from NgModules. They discover loadComponent. It's simpler, requires less boilerplate, and feels aligned with where Angular is heading. So they start replacing loadChildren calls across the routing configuration — one by one, sometimes all at once.

The build passes. The application behaves exactly as before. Bundle reports may even suggest the migration was a success.

The problem is that routing decisions are judged by what happens immediately after deployment. Architectural decisions are judged six months later.

I've reviewed migrations where every loadChildren route was replaced with loadComponent in a single PR. The application kept working. Six months later the route structure no longer reflected the application's feature boundaries. Ownership became harder to understand. Shared concerns started leaking across routes. The routing configuration became flatter — but not simpler. One of those reviews turned into a two-sprint refactor that the team hadn't budgeted for.

Angular 19 made standalone the default. New projects no longer generate NgModules, which means loadComponent is now the first lazy-loading API many developers encounter. That makes the distinction between these two APIs more important than ever — not less.

This article is not about which API is newer. It's about understanding the architectural boundary each one creates, and why treating them as interchangeable is a mistake that compounds quietly over time.

What Angular Actually Says

The Angular routing documentation is accurate but brief on this distinction.

loadComponent lazily loads a single standalone component when its route becomes active. loadChildren lazily loads a set of child routes — typically from a separate routes file. Both use dynamic import() under the hood. Both are fully supported in modern Angular.

The documentation stops there. The architectural reasoning is left to the reader, which is where most of the confusion starts.

The Architectural Difference: Component Boundary vs Feature Boundary

The surface-level difference is obvious: one loads a component, one loads routes.

The more important difference is the scope of the lazy-loading boundary.

loadComponent creates a boundary around a single screen. When a user navigates to /help, Angular loads HelpComponent and nothing else.

loadChildren creates a boundary around a feature domain. When a user navigates to /admin, Angular loads a route configuration that may contain dozens of child routes, shared providers, feature-specific guards, and related components — all bundled together as a cohesive unit.

// loadComponent — boundary is one screen
{
  path: 'help',
  loadComponent: () => import('./help/help.component').then(m => m.HelpComponent)
}

// loadChildren — boundary is an entire feature domain
{
  path: 'admin',
  loadChildren: () => import('./admin/admin.routes').then(m => m.adminRoutes)
}

Visualising where boundaries should sit makes this clearer:

Application
│
├── /help          → loadComponent   (isolated screen, no sub-routes)
├── /about         → loadComponent   (isolated screen, no sub-routes)
├── /terms         → loadComponent   (isolated screen, no sub-routes)
│
├── /admin         → loadChildren    (feature domain)
│   ├── /users
│   ├── /users/:id
│   ├── /roles
│   └── /audit
│
├── /dashboard     → loadChildren    (feature domain)
│   ├── /analytics
│   └── /reports
│
└── /checkout      → loadChildren    (feature domain — shared state, sequential flow)
    ├── /cart
    ├── /shipping
    └── /payment

The question is never "which API is more modern." The question is: where should the lazy-loading boundary exist for this part of the application?

Dimension	loadComponent	loadChildren
Lazy-loading scope	Single component	Feature route set
Chunk granularity	Component-level	Feature-level
Route organisation	Flat	Hierarchical
Shared providers	Possible but duplicated across routes	Grouped at feature level, scoped to feature lifetime
Route-level providers	Supported, but scoping breaks down at scale	Naturally scoped via parent route `providers` array
Guard and resolver inheritance	Must be repeated per route	Applied once at the feature boundary
Scalability	Good for isolated pages	Good for feature domains
Team ownership	Per-route	Per-feature file

When loadComponent Works Best

Some routes are genuinely independent. They have no sub-navigation. They don't share services with adjacent routes. They don't need their own route hierarchy.

Good candidates:

/help — static content, visited rarely
/about — no dependencies on feature services
/terms, /privacy — purely informational
/error — error boundary pages
A lightweight settings landing page that links out to deeper sections

For these routes, loadComponent is the right answer. There's no feature boundary to model, no shared providers to group, and no sub-routes that logically belong together.

export const routes: Routes = [
  {
    path: 'help',
    loadComponent: () => import('./help/help.component').then(m => m.HelpComponent)
  },
  {
    path: 'about',
    loadComponent: () => import('./about/about.component').then(m => m.AboutComponent)
  },
  {
    path: 'terms',
    loadComponent: () => import('./legal/terms.component').then(m => m.TermsComponent)
  }
];

No extra route file. No unnecessary abstraction. Just a lazy-loaded screen.

When loadChildren Is the Correct Architecture

Now consider an admin area. It contains user management, role configuration, audit logs, reporting, and a dashboard. These routes share services. They share guards. They have their own sub-navigation. They belong to the same business domain and are typically owned by the same team.

Here's what it looks like when loadComponent is overused on a feature domain:

// What this looks like when loadComponent is applied to a feature domain
export const routes: Routes = [
  { path: 'admin/dashboard', loadComponent: () => import('./admin/dashboard/dashboard.component').then(m => m.DashboardComponent) },
  { path: 'admin/users', loadComponent: () => import('./admin/users/users.component').then(m => m.UsersComponent) },
  { path: 'admin/users/:id', loadComponent: () => import('./admin/users/user-detail.component').then(m => m.UserDetailComponent) },
  { path: 'admin/roles', loadComponent: () => import('./admin/roles/roles.component').then(m => m.RolesComponent) },
  { path: 'admin/audit', loadComponent: () => import('./admin/audit/audit-log.component').then(m => m.AuditLogComponent) },
];

This flat structure has real costs. Guards and resolvers must be repeated on every route individually. Providers must either be hoisted to root — where they live for the entire application lifetime — or duplicated across route definitions. Child route hierarchy is gone: /admin/users/:id is now a peer of /admin/dashboard at the application level rather than a child of /admin/users. Ownership is unclear.

Here's what it should look like:

// Feature domain correctly modelled as loadChildren
export const routes: Routes = [
  {
    path: 'admin',
    loadChildren: () => import('./admin/admin.routes').then(m => m.adminRoutes),
    providers: [
      AdminUserService,
      AdminAuditService,
    ]
  }
];

And inside admin.routes.ts:

export const adminRoutes: Routes = [
  {
    path: '',
    canActivate: [AdminGuard],
    children: [
      { path: 'dashboard', loadComponent: () => import('./dashboard/dashboard.component').then(m => m.DashboardComponent) },
      { path: 'users', loadComponent: () => import('./users/users.component').then(m => m.UsersComponent) },
      { path: 'users/:id', loadComponent: () => import('./users/user-detail.component').then(m => m.UserDetailComponent) },
      { path: 'roles', loadComponent: () => import('./roles/roles.component').then(m => m.RolesComponent) },
      { path: 'audit', loadComponent: () => import('./audit/audit-log.component').then(m => m.AuditLogComponent) },
    ]
  }
];

This structure does several things the flat version cannot:

AdminGuard is applied once at the feature boundary, not repeated on five routes
AdminUserService and AdminAuditService are scoped to the admin feature — instantiated when the admin section loads, destroyed when the user leaves it (assuming default router configuration without a custom RouteReuseStrategy)
/admin/users/:id is correctly a child of /admin/users, not an application-level peer
The admin team owns and modifies admin.routes.ts without touching the root routing configuration
Route data, breadcrumb metadata, and analytics identifiers cascade naturally to all child routes

Worth calling out explicitly: loadComponent does support a providers array. The technical limitation isn't that providers are unavailable — it's that when five sibling routes all need the same service, you either duplicate the provider declaration across all five or hoist it to root. Neither is correct. loadChildren solves this cleanly because the scoping boundary and the feature boundary are the same thing.

The architectural signal is straightforward: if you find yourself writing admin/ as a prefix on five separate loadComponent routes, you've missed a feature boundary.

A Note on Chunk Count and Preloading

It's tempting to treat more lazy chunks as automatically better. I've seen teams celebrate an increase in lazy-loaded chunks without measuring the actual impact. That's optimising an assumption, not a result.

More chunks mean more network requests. Whether that matters depends heavily on your preloading strategy. With PreloadAllModules or QuicklinkStrategy, Angular preloads lazy chunks in the background after initial load — which means chunk granularity becomes less critical for perceived performance. With no preloading, a large feature chunk loaded on first navigation to /admin is a real cost.

Before restructuring routes for bundle reasons, run ng build --stats-json and load the output into Webpack Bundle Analyzer. Measure the before and after. If you haven't measured, you haven't optimised — you've just changed things.

Common Mistakes

Replacing every loadChildren call with loadComponent during a standalone migration.
This is the most common mistake I see. Standalone components and route architecture are separate concerns. A standalone component works perfectly inside a loadChildren route file. Migrating one does not require changing the other. I've reviewed PRs where an engineer replaced every loadChildren call in a single commit and labelled it a "standalone migration" — it wasn't. It was an architectural change that happened to compile cleanly.

Losing hierarchical route structure.
When loadChildren is replaced with flat loadComponent routes, child route hierarchy disappears. Guards, resolvers, and providers that once applied at the feature level must now be repeated per route. This surfaces in code review as canActivate: [AuthGuard] duplicated across every admin route — a clear sign that a feature boundary was missed.

Treating standalone components as an architecture strategy.
Standalone components improve dependency declaration and compilation. They say nothing about how routes should be organised. The routing structure decisions still belong to the engineering team.

Optimising without measuring.
Run bundle analysis before and after any routing restructure. Smaller bundles are not automatically better. More chunks are not automatically better. Your preloading strategy changes what "better" means.

When loadChildren Is Overkill

The case for loadChildren at feature boundaries holds for medium-to-large applications. It is not universally correct.

A small internal tool. A side project. A marketing site. A single-team application with eight routes. These gain little from introducing route files and feature boundaries everywhere. The abstraction costs more than it saves.

The honest rule: use loadChildren when the feature boundary is real — when there are multiple related routes, shared providers, and a clear reason to group them together. Don't introduce it to impose large-application structure on a codebase that isn't there yet. Premature route architecture is still premature optimisation.

The inflection point is usually recognisable: when you find yourself duplicating guards across related routes, or when a new developer can't tell which routes belong together by reading the root configuration, the feature boundary has been missed and loadChildren will pay for itself quickly.

What I Use in Production

On a 600+ component Angular platform serving enterprise clients, both strategies coexist and have distinct jobs.

Feature domains — client configuration, reporting, user administration, the main product dashboard — all use loadChildren. These are coherent domains with their own providers, guards, and sub-navigation. Fragmenting them into individual loadComponent calls would make the routing configuration harder to read and the feature boundaries harder to maintain. In a monorepo, these feature route files map directly to library boundaries, which means the routing structure reflects actual team ownership.

Isolated screens — the help centre, terms pages, error boundaries, and a handful of rarely visited informational pages — use loadComponent. No sub-routes, no shared dependencies, no reason to create a route file.

Nobody on the team debates the APIs in isolation. The conversation is usually about ownership, shared dependencies, and deployment boundaries. The routing decision follows from those answers.

Decision Matrix

Scenario	Recommendation	Reason
Help / About / Terms pages	`loadComponent`	Isolated, no sub-routes, no shared dependencies
Error boundaries	`loadComponent`	Independent, no feature services
Admin area	`loadChildren`	Feature domain with sub-routes, shared guards, shared services
Reporting dashboard	`loadChildren`	Multiple related routes, shared data services
Multi-step checkout flow	`loadChildren`	Shared state, guards, sequential child routes
User account section	`loadChildren`	Profile, billing, security — related routes with shared context
Marketing pages	`loadComponent`	Independent, no feature services
Small internal tool (<8 routes total)	`loadComponent`	Overhead of feature files not justified
Feature-rich business domain	`loadChildren`	Architecture boundary, not just a routing convenience

Final Thoughts

Most routing mistakes aren't caused by choosing the wrong API. They're caused by placing the lazy-loading boundary in the wrong place.

loadComponent works best when a route represents a genuinely independent screen — one component, no children, no shared dependencies.

loadChildren works best when a route represents a feature domain — a coherent set of routes that share providers, guards, and ownership.

The strongest Angular routing configurations use both. Not because mixing APIs is sophisticated, but because real applications contain both isolated screens and feature domains. The routing configuration should reflect that honestly.

When evaluating a route, I've stopped asking "which API should I use?" I ask: what is the actual boundary here?

If the answer is "a page," I reach for loadComponent.

If the answer is "a feature," I reach for loadChildren.

Once the boundary is clear, the API choice is obvious.

If you're in the middle of a standalone migration and replacing loadChildren calls wholesale — slow down. Ask whether each replacement is an architectural decision or a syntax preference. The answer is not always the same, and the difference matters six months from now.

References

I write about frontend problems from real projects — follow if that's useful.

If this helped, drop a ❤️ — it helps with visibility.

Connect with me:

LinkedIn: Sanket Bhor
Website: sanketbhor.dev

The Stylelint Rule That Was Silently Rewriting Our SCSS Colors

Sanket Bhor — Thu, 28 May 2026 20:30:12 +0000

A colleague flagged something odd in a PR review — our SCSS colors had changed. Not broken, just different. rgba(0, 0, 0, 0.7) had quietly become rgb(0, 0, 0, 0.7) across dozens of files. The a was just gone. Nobody on the team had touched those lines.

No error. No warning. Just silent rewrites on every save.

Took us a while to trace it back, but it was one line in .stylelintrc.

The rule

"color-function-notation": "legacy"

My first thought was — okay, "legacy" means keep the old syntax. That's literally what the word means. And technically it does enforce the older comma-separated format, so that part tracks.

The issue was our codebase had gotten inconsistent. Some files had already picked up modern rgb() syntax through updated dependencies. The rest still used rgba(). When Stylelint's auto-fix kicked in, it just... normalised everything. Aggressively. Didn't ask, didn't warn. Hundreds of color changes in commits that had nothing to do with colors.

What each value does

Value	What it enforces
`"modern"`	`rgb(0 0 0 / 0.7)` — space-separated, slash for alpha
`"legacy"`	`rgba(0, 0, 0, 0.7)` — traditional comma-separated alpha syntax
`null`	Nothing — leaves your code exactly as you wrote it

What we actually saw in our project was rgba() being rewritten to rgb(..., alpha) — not the standard modern space-separated conversion. More on that below.

Worth knowing: none of this happens without auto-fix. If you're just running Stylelint normally, it warns. The actual rewrites only happen when you run stylelint --fix, have a CI step with --fix enabled, or have format-on-save turned on in your editor.

Why this one is easy to miss

A lot of articles about color-function-notation talk about the dramatic conversion — rgba(0, 0, 0, 0.7) turning into rgb(0 0 0 / 0.7). Space-separated, slash before alpha, completely different looking. Hard to miss.

What we got was quieter:

Before: rgba(0, 0, 0, 0.7)
After: rgb(0, 0, 0, 0.7)

Same commas. Same numbers. Just the a missing. In a busy PR review across dozens of files, that's almost invisible.

And it's not purely cosmetic either. For us the issue showed up as diff noise — but depending on your setup, silent rewrites like this can have downstream effects worth watching for.

For us honestly the bigger headache was just the diff noise. PR history full of color changes nobody made. Not ideal.

One thing to check first

If you're using stylelint-config-standard-scss — most Angular projects do — this rule is already on inside the preset, set to "modern". So even if you never added it yourself it might already be running. Before changing anything, figure out if it's in your own config or coming from the preset. That changes where you need to override it.

In our case it was explicitly set in our own .stylelintrc:

{
  "extends": ["stylelint-config-standard-scss"],
  "rules": {
    "color-function-notation": "legacy"
  }
}

Ways to fix it

There's no one-size-fits-all here.

Option 1 — Just turn it off

{
  "rules": {
    "color-function-notation": null
  }
}

Stylelint leaves your color syntax alone entirely. No rewrites, no warnings.

Good for: when you just need the noise to stop right now.

Downside: mixed syntax sticks around forever if you never come back to it.

Option 2 — Clean it up properly, separately

{
  "rules": {
    "color-function-notation": "modern"
  }
}

Set it to "modern" and do one isolated cleanup PR — just this, nothing else mixed in. Audit your SCSS before running auto-fix.

Good for: when you want consistency and have time to do it properly.

Downside: needs some prep work. Don't just flip it and run.

Option 3 — Scope it with `overrides`

{
  "overrides": [
    {
      "files": ["**/*.scss"],
      "rules": {
        "color-function-notation": null
      }
    }
  ]
}

Keeps the rule active for CSS, disables it for SCSS only. More precise than a global disable and way cleaner than scattering /* stylelint-disable */ comments across your whole project.

Good for: when you want enforcement on CSS but your SCSS theming files need to be left alone.

Downside: bit more config, but honestly manageable.

What we did

Went with null. Stopped the noise, unblocked the team the same day. Will come back with a proper cleanup PR when things settle down. One thing at a time.

If it's happening on every save locally

Check VS Code before you go debugging your pipelines.

The Stylelint extension has this:

"stylelint.autoFixOnSave": true

When that's on, --fix runs silently every single save. Seen teams spend a long time pointing fingers at CI when it was their own editor config the whole time.

How to know if this is your issue

Color changes showing up in diffs nobody made
PR reviews catching rgba → rgb changes out of nowhere
Weird rendering after running stylelint --fix

Check your .stylelintrc, .stylelintrc.json, or stylelint.config.js for color-function-notation. And check your extended presets too — it might not even be in your own config.

tl;dr

Stylelint auto-fix on an inconsistent codebase will rewrite things you didn't ask it to rewrite. The color-function-notation rule is one of the quieter offenders because the change it makes — rgba to rgb — is easy to overlook.

Check your config, check your presets, and don't run auto-fix blind.

I write about frontend problems from real projects — follow if that's useful.

If this helped, drop a ❤️ — it helps with visibility.

Connect with me:

LinkedIn: Sanket Bhor
Website: sanketbhor.dev

DEV Community: Sanket Bhor

GitHub Copilot dropped flat pricing on June 1st. Now it's usage-based — AI credits, Actions minutes, all metered. Solo devs won't notice. Teams with heavy PR automation? Audit your usage before the bill does it for you.

You're Not Paying for Code Generation. You're Paying for Context

The hidden cost of AI isn't generating code. It's understanding your codebase.

Two Prompts, Two Very Different Problems

Why Agent Workflows Feel Different From Autocomplete

The Log File Trap

What Changed for Me

Final Thoughts

loadComponent vs loadChildren in Angular 19: Choosing the Right Lazy-Loading Boundary

What Angular Actually Says

The Architectural Difference: Component Boundary vs Feature Boundary

When loadComponent Works Best

When loadChildren Is the Correct Architecture

A Note on Chunk Count and Preloading

Common Mistakes

When loadChildren Is Overkill

What I Use in Production

Decision Matrix

Final Thoughts

References

The Stylelint Rule That Was Silently Rewriting Our SCSS Colors

The rule

What each value does

Why this one is easy to miss

One thing to check first

Ways to fix it

Option 1 — Just turn it off

Option 2 — Clean it up properly, separately

Option 3 — Scope it with overrides

What we did

If it's happening on every save locally

How to know if this is your issue

tl;dr

Option 3 — Scope it with `overrides`