DEV Community: Karol Modelski

The Hidden Nightmare of Scaling Massive Angular Monoliths

Karol Modelski — Thu, 25 Jun 2026 08:00:00 +0000

Everyone loves to talk about new frameworks.

Almost nobody wants to talk about what most senior Angular devs actually live in every day:

a 6+ year old enterprise app,
one Angular “app” that’s actually 40 products,
20+ minute build times on CI,
circular dependencies hiding in every corner.

The docs tell you:

Use esbuild. Use Nx. Use module boundaries. Problem solved.

Then you try it in a real bank, healthcare, or legacy SaaS codebase and discover:

you didn’t adopt a tool,
you adopted a new category of pain.

Modern tooling doesn’t magically fix legacy monoliths. It just makes their problems visible — and sometimes even more expensive.

When “Just Switch to esbuild” Turns Into “Why Is This Build 30 Minutes Now?”

esbuild is a genuinely impressive piece of technology:

extremely fast bundling,
great for modern Angular apps,
lighter config than classic Webpack.

But real-world reports from large Angular monoliths are… mixed:

teams migrating from Webpack to esbuild see blazing fast local builds,
then discover production or CI builds get slower or more fragile because of chunking and splitting behavior in huge apps.

One Nx issue described:

a module federation setup where initial build time jumped from ~90 seconds to close to 30 minutes after changes — due to complex chunking strategies and the way dependencies were wired.

In another case, a team with “one of the largest monolithic Angular apps in the world” moved to esbuild and ended up with:

local dev: better,
production bundling: complicated chunk management,
final solution: two separate projects in angular.json — esbuild for dev, Webpack for prod.

That’s not a failure of esbuild.

It’s what happens when you bolt a modern bundler onto an app that:

was never designed with clear boundaries,
uses dynamic imports everywhere,
and treats lazy-loaded routes as a dumping ground.

f your architecture is a junk drawer, a faster compiler just lets you open the drawer quicker. It doesn’t organize what’s inside.

Nx, Monorepos, and the “Modularization Will Save Us” Myth

Nx and monorepos can be game-changers when used from the start:

incremental builds,
affected-only testing,
module boundaries enforced,
CI time dropping from ~20 minutes to under 2 in large, well-designed workspaces.

But migrating a giant, messy Angular app into Nx is where a lot of teams hit the Enterprise Monolith Trap.

You:

drop the app into an Nx workspace,
run nx graph,
discover a terrifying dependency diagram with cycles everywhere.

The docs tell you:

enable @nx/enforce-module-boundaries,
break circular dependencies by moving shared pieces into new libraries,
create a clean layer structure.

All correct.

But on a legacy app, that means:

weeks or months of refactoring just to make the tooling happy,
teams blocked on breaking cycles instead of shipping features,
regression risk across critical flows when you move “shared” code around.

Talks about modular monoliths show beautiful patterns:

clear domain layers,
private APIs,
top-down dependency rules.

In greenfield projects, that works brilliantly.

In a legacy enterprise frontend, you’re often starting from:

shared utils imported directly from /src/app everywhere,
cross-feature imports that ignore any sense of boundaries,
tight coupling between “unrelated” modules because of convenience imports.

Nx doesn’t turn your monolith into a modulith. It just stops pretending your monolith is fine — and forces you to pay down chaos you’ve been borrowing against for years.

The Silent Killer: Build Pipelines That Eat Your Day

The biggest productivity killer in large Angular apps usually isn’t the framework.

It’s the pipeline.

Symptoms you see in banks, healthcare, and legacy SaaS:

10–30 minute builds in CI for every branch.
pipelines that must run extra code generators (proxies, API clients, etc.) before Angular even starts building.
flaky steps: tests, lints, and bundlers failing intermittently, forcing devs to rerun jobs.
“tiny” changes that still trigger full rebuilds because incremental builds weren’t designed in from the start.

Nx can help with:

caching,
incremental builds,
rebuilding only what changed.

But only if you’ve:

actually split code into buildable libraries,
wired all apps and libs to use the right executors,
aligned build target names across projects and libraries (or targetDefaults) so incremental executors can work.

Otherwise you get the worst of both worlds:

Nx complexity,
plus still building everything, every time.

And if your build also:

runs abp CLI proxies,
bundles multiple Angular apps,
packs everything into a deployment artifact,

you end up with a pipeline where nobody truly understands which step is slow, only that the whole thing is crushing morale.

You can’t have a healthy engineering culture if every experiment costs you a 30-minute CI penalty.

When “Just Modularize It” Becomes a Multi-Year Migration Trap

Enterprise talks make modularization sound simple:

extract domains into libraries,
define boundaries,
profit.

In reality, long-lived Angular apps usually have:

features that started as experiments and became core products,
modules that secretly depend on each other in both directions,
design systems and shared components that leak business logic.

When you try to modularize this:

you discover dozens or hundreds of circular dependencies.
you create “shared” libraries that quickly become new dumping grounds,
you end up either: — endlessly slicing code into more libs, or — merging libs back together because cycles are unmanageable.

The official Nx guidance on circular dependencies is sensible:

move small pieces from one project to another,
create a new shared lib for common dependencies,
or merge two libraries if they’re truly inseparable.

But in legacy frontends, everything feels inseparable:

because business logic and UI are tangled,
because features were never designed as domains,
because “shared” abstractions depend on concrete modules.

You can absolutely succeed with gradual modularization.

You just can’t pretend:

it’s a “quick Nx migration,”
or that tools alone will rescue you without rewriting some business logic and boundaries.

Large-scale migration isn’t a strategy. It’s what you call it when you don’t want to admit you’re rewriting while pretending you’re just ‘moving things around’.

The Enterprise Developer’s Reality: You’re Not Doing It Wrong

If you’re maintaining a massive Angular monolith, you’re probably:

doing on-call for a business-critical system,
juggling EOL reminders (Angular 19 end-of-life, libs that are no longer maintained),
forced to be cautious about every “cool” refactor because downtime has real cost.

When blog posts and conference talks say:

“Just adopt esbuild, it’s 10x faster,”
“Just move to an Nx monorepo,”
“Just break everything into micro frontends,”

they often ignore:

regulatory constraints,
long CI pipelines you can’t rewrite from scratch,
the risk of mass refactors in a system nobody fully understands anymore.

Your frustration is not a lack of skill.

It’s a rational response to:

brittle pipelines,
historical decisions,
and tools that were designed for idealized codebases.

Enterprise frontends aren’t broken because seniors are clueless. They’re broken because trade-offs compound — and tools arrived ten years after the architecture was decided.

What Actually Helps: Constraints, Not Silver Bullets

If you’re responsible for one of these monsters, here’s the boring but effective playbook grounded in what real teams report:

Accept the monolith, then modularize within it

Think “modulith” before micro frontends: one deployable, internally modular. — Introduce clear layers and boundaries gradually — not everything at once.

Fix the worst pipeline bottlenecks first

Profile where time actually goes: bundling, tests, codegen, artifact uploads. — Use Nx incremental builds where possible, even if only for part of the codebase at first.

Use tools to reveal problems, not to declare victory

nx graph to see dependency chaos. — @nx/enforce-module-boundaries to prevent new damage while you slowly untangle the old.

Treat circular dependencies as design feedback, not just lint errors

if two libs constantly depend on each other, maybe they’re the same domain; merge them. — if “shared” is depending on “feature,” you don’t have a shared lib — you have inverted design.

Limit how many technologies you add to the party

don’t add module federation, custom bundlers, a new design system, and a new monorepo in the same quarter. — every move that touches build + architecture at once multiplies risk.

The goal isn’t to turn your enterprise monolith into a conference talk. It’s to make it slightly less painful every quarter without blowing it up in production.

I’m an Independent Technology Partner for SMEs. If you’re looking to optimize your architecture or accelerate your MVP, let’s connect at karolmodelski.pl.

Why “Building in Public” Is Hollowing Out Your Developer Career

Karol Modelski — Thu, 18 Jun 2026 08:00:00 +0000

Somewhere in the last few years, “being a developer” quietly turned into “being a content creator with VS Code open in the background.”

You’re told to:

post daily on X,
share screenshots on LinkedIn,
thread your way to a “personal brand,”
and narrate every micro-step of your side project like a reality show.

If you’re honest, a lot of it doesn’t feel like growth.

It feels like performance.

The industry told you to build in public to grow your career. What it often did instead was trade your deep work for a never‑ending cycle of performative updates.

The Illusion of “Building in Public” as Career Growth

In theory, building in public has real benefits:

you share your journey,
you attract collaborators and users,
you get feedback early,
you build trust over time.

In practice, a lot of devs experience something closer to this:

pressure to post even when there’s nothing meaningful to say,
anxiety about negative feedback and nitpicking, especially early on,
a creeping sense that the project now exists for the timeline, not for users.

Founders and solo builders have already started saying:

building in public added pressure and opened them up to criticism before they were ready;
sharing every step sometimes attracted the wrong audience — other builders, not actual customers.

For developers, it’s even worse:

your “work” isn’t just code; it’s suddenly threads, carousels, and engagement metrics.

Building in public can work when it’s in service of a real product. When it becomes its own product, your career quietly turns into a content channel.

Hustle Culture in a Hoodie: When “Community” Is Just a Content Farm

Scroll LinkedIn or X long enough and you’ll see the same formula:

“Day 27 of building my SaaS in public.”
“Five lessons I learned shipping this tiny feature.”
“Here’s how I grew from 0 to 10k impressions in a month.”

It looks like community.

Underneath, it’s often:

everyone broadcasting,
almost nobody actually talking,
endless “value posts” designed to farm engagement, not build relationships.

Hustle culture research is very clear:

constant pressure to be “always on,” visible, and optimizing yourself is a fast path to burnout;
people burn out not from hard work alone, but from tying their identity and worth to constant output and public performance.

“Developer community” can quietly morph into:

a place where you perform your progress to be seen as serious,
instead of a place where you can be confused, wrong, and still belong.

If every post needs to be ‘high value,’ you’re not in a community — you’re on a stage. And you can’t do deep engineering from a stage.

The Myth of Networking: Why Most “Connections” Feel Empty

A lot of dev networking advice sounds like this:

comment on 20 posts a day,
DM people with a “value offer,”
build a pipeline of leads,
track your interactions like a CRM.

No wonder networking feels gross.

When you see people as:

“targets,”
“leads,”
“potential collabs,”

every interaction becomes a bit of a transaction.

Writers on networking point out:

transactional networking focuses on what you get and what you give right now;
real, long-term networking looks more like friendships: shared curiosity, vulnerability, mutual support without immediate ROI.

The developer version of this:

boosting each other’s posts,
trading likes and “fire thread bro,”
without ever actually reading each other’s code, docs, or ideas.

If your “network” disappears the moment you stop posting, you didn’t build relationships. You built an audience with commitment issues.

Deep Work vs. Shallow Visibility: What Actually Moves Your Career

Here’s the part almost no “build in public” thread admits:

High-quality engineering work still comes from long, quiet, cognitively demanding sessions — deep work.

Deep work for engineers looks like:

designing or refactoring serious systems,
debugging hairy production issues,
learning technologies deeply enough to bend them, not just copy patterns.

Shallow work looks like:

checking analytics,
replying to on-platform comments,
cranking out posts to stay “top of mind,”
tweaking your “personal brand.”

Productivity research keeps finding the same thing:

deep work blocks (60–90 minutes, protected from distraction) are where engineers produce lasting value;
constant context-switching into social apps and content creation erodes your ability to concentrate and reason deeply.

Even content people are starting to say:

meaningful writing and creative work also need deep work;
churning out fast food content creates attention, not substance.

So when developers try to:

be great engineers,
be consistent content creators,
be always-on networkers,

they’re effectively trying to run three cognitively expensive careers at once.

You can either optimize for long-term leverage in your skills, or for daily impressions. Pretending you can do both at scale is how you quietly burn out.

How to Grow Your Career Without Becoming a “Content Creator”

If building in public and hustle-flavored networking feel wrong to you, good.

You’re not anti-growth. You’re allergic to nonsense.

There is a quieter, more sustainable path.

1. Trade public performance for small, real circles

Instead of:

broadcasting to thousands you don’t know,

do this:

join or form a small group (3–8 devs) around a stack or topic you care about.
meet regularly (monthly/bi-weekly) to: — review each other’s code, — share real problems, — talk about trade-offs and decisions.

This is closer to genuine networking research:

relationships built around vulnerability and mutual help, not transactions.

2. Treat deep work as your primary “brand”

Your actual career capital is:

systems you’ve built,
migrations you’ve survived,
incidents you’ve handled well,
weird bugs you’ve debugged and understood.

Protect daily deep work blocks like meetings:

60–90 minutes a day where Slack, socials, and posting are off.
learn, design, or build something hard, then document it privately first (notes, ADRs, internal docs).

You’ll have far more to say publicly later if and when you choose.

3. Share selectively, not compulsively

You don’t owe the internet your process.

A healthier rhythm:

focus on building for weeks or months,
periodically share one well-thought-through post: — “Here’s how we solved X at Y scale.” — “Here’s a migration that hurt, and why I’d do it differently.”

Quality over cadence.

As even pro‑content people admit: resonant work takes time.

4. Network like a human, not a funnel

When you reach out:

reference something specific you actually read or used,
offer something small but real (a useful comment, a perspective, a resource),
be okay if nothing “converts” immediately.

Long-term networking research is blunt:

real opportunities come from a handful of strong ties built on trust and vulnerability, not from hundreds of shallow interactions.

The most valuable developer network you’ll ever have fits into a group chat, not a follower count.

The Quiet Flex: Being Good at the Boring Parts

The irony of all this is simple:

the people shipping the most meaningful work are often too busy doing it to narrate every step;
the loudest “builders in public” are sometimes optimizing more for perception than for durable skill.

If you want a career that actually compounds, not just one that looks impressive on social media:

get uncomfortably good at deep, focused engineering work;
cultivate a small, honest circle of peers with whom you can be wrong, confused, and ambitious;
share publicly when you genuinely have something to say — not because the algorithm demands a sacrifice.

You don’t have to become a thought leader.

You don’t have to “build in public” every commit.

You just have to:

keep learning in private,
keep shipping in reality,
and build a handful of relationships strong enough to survive even if you never post again.

The best thing you can do for your developer career is not to become more visible. It’s to become someone worth finding, even if you’re quiet.

I’m an Independent Technology Partner for SMEs. If you’re looking to optimize your architecture or accelerate your MVP, let’s connect at karolmodelski.pl.

Angular State Management: The Never-Ending Search for the “Perfect” Architecture

Karol Modelski — Thu, 11 Jun 2026 08:00:00 +0000

Nothing exposes developer anxiety like the words “state management” in an Angular enterprise project.

You have:

Signals,
SignalState,
SignalStore,
classic NgRx Store,
NGXS,
custom services as “mini-stores.”

And then you have a room full of mid and senior devs trying to design a system that has to survive five years of shifting requirements and team churn.

So what happens?

three weeks of meetings,
fourteen architecture diagrams,
benchmarking discussions nobody will ever repeat in practice.

Modern Angular state management gives you better primitives than ever. It also gives you a hundred new ways to overthink yourself into paralysis.

The State Management Buffet: Too Many Good Options, Not Enough Discipline

The ecosystem in 2025–2026 is not short on tools:

Plain Signals — built-in, zero-dependency, great for local or feature-level state.
SignalState / lightweight stores — NgRx’s signal-based API for smaller, isolated state, often at component or feature level.
SignalStore — structured, centralized state with Signals under the hood, meant for shared or domain-level state.
Classic NgRx Store — the “enterprise classic”: actions, reducers, effects, selectors, time-travel DevTools.
NGXS and others — simpler Redux-like abstractions trying to cut boilerplate.

Every blog post ends the same way:

There is no single best solution. It depends on your project size, team structure, and complexity.

Which is true.

And completely unhelpful when you have to make a call.

We keep asking “What’s the best state library?” when the better question is “How many different patterns can our team realistically keep in their heads?”

Decision Paralysis: The Architecture That Exists Only in Miro

The most realistic description of state management in large Angular apps right now looks like this:

State in services.
State in components.
State in classic NgRx.
State in SignalStore.
A few experiments with NGXS or Akita leftover from previous phases.

No single source of truth.

No single mental model.

What you do have:

a beautiful architecture diagram in Miro,
a 40-minute Loom recording titled “State Management Strategy v3.1,”
and a repo where every feature team solved state differently based on whichever conference talk they watched last.

Developers on Reddit and LinkedIn keep saying the same thing:

“Please don’t use Redux everywhere.”
“Have an explicit, consistent way of dealing with state across the application(s).”
“Pick two or three patterns and stick with them.”

The over-engineering trap is not picking NgRx or Signals.

The trap is:

trying to design a state architecture that covers every possible future scenario,
while your current codebase quietly rots under the weight of indecision.

Architecture diagrams don’t reduce complexity. Shipping boring, consistent patterns does.

The Over-Engineering Trap: Chasing the Perfect Store While Ignoring the Code

Here’s how over-engineered state management usually happens:

Someone reads a “Complete Guide to NgRx SignalStore” and gets excited.
Someone else wants classic NgRx for DevTools and strict flows.
Another person says “Signals alone are enough; stores are overkill.”

So you compromise:

global NgRx Store for “core” state,
SignalStore for some features,
local Signals in some components,
a few services still holding state because nobody had time to migrate them.

You spend weeks:

debating event plugins, inter-store communication, DDD boundaries,
arguing about whether shared state belongs in domain stores or feature stores.

Meanwhile, the things that actually kill scalability are much more boring:

services doing too many things at once,
no clear separation between server state and client state,
child components that both own and consume state,
APIs that force ugly workarounds no matter which store you use.

Most enterprise apps don’t collapse because they picked the ‘wrong’ state library. They collapse because nobody enforced simple rules on where state is allowed to live.

What the Tools Are Actually Good At (When You Use Them Like an Adult)

If you strip away the hype, the recent state of Angular guidance is surprisingly sane.

A lot of solid resources converge on a simple mapping:

Plain Signals

— for local, primitive or small, isolated state (component or small feature).
SignalState / lightweight stores

— for local but more complex objects or nested state, where you want structure without full-blown store ceremony.
SignalStore

— for shared, structured, domain-level or global state that needs to outlive components and be consumed across features.
Classic NgRx Store

— when you truly need Redux-style traceability, advanced DevTools, or are maintaining an existing NgRx-heavy codebase.

Summarized nicely in one article:

local, primitive → plain Signals ,
local, complex → SignalState ,
global, structured → SignalStore ,
complex orchestration / events between stores → SignalStore + Events plugin.

The problem is not that this mapping is wrong.

The problem is that many teams:

treat every feature as “global, complex, mission-critical,”
default to the heaviest tool for everything,
or mix all tools with no clear boundary.

Signals didn’t make NgRx obsolete. NgRx didn’t make services obsolete. The only thing that’s obsolete is pretending one hammer is right for every nail.

The Real Cost: State Strategy as a Drag on Scalability

State management was supposed to create scalability.

Instead, in many teams, it is killing it.

Ways state strategy makes things worse:

Onboarding pain

New devs have to learn: “In this feature we use Signals; over here we use SignalStore; for this legacy part we use classic NgRx.”
Inconsistent mental models

Some features mutate state in stores, some in services, some in components. No one can answer “Where does this value actually live?” without a search party.
Over-abstracted logic

Simple flows are buried in generic reducers or over-generic SignalStores instead of simple functions or services.
Cross-store complexity

Lightweight stores in multiple layers (UI, feature, domain, util) needing coordination, risking redundancy and cycles if you’re not careful.

Architects dealing with SignalStore are already warning:

don’t let stores talk to each other directly,
use orchestration services and events,
be deliberate about where stores live in your layered architecture.

All of that is fine — if you’re actually using those ideas to simplify.

Most teams don’t reach that stage.

They stall earlier, in analysis paralysis.

State management is supposed to remove accidental complexity. When your state strategy requires a diagram and a workshop to explain, you’ve just relocated the complexity instead of reducing it.

A Simpler Way to Think: Rules Instead of Endless Debates

You don’t need a perfect state architecture.

You need a few clear rules that everyone can remember.

For example (adapted from community guidance and modern best practices):

Default to Signals + services

For most feature-level state, create a service with Signals and computed values. — Expose readonly Signals and methods; keep mutation inside.

Use SignalStore for real shared state

Domain-level data used across multiple features? — Long-lived app-wide state? — Use SignalStore and keep all business logic there.

Keep classic NgRx where it already works

If you already have NgRx and it’s doing its job, don’t “rewrite to Signals” just because it’s trendy. Introduce SignalStore gradually for new areas.

Limit yourself to 2–3 patterns app-wide

For example: — plain Signals in components for simple UI bits, — Signal-based services for feature state, — SignalStore for shared state. — Everything else needs a very strong justification.

Explicitly document “when to use what”

One short ADR or page: — “If your state only matters to this component → do X” — “If it’s shared within a feature → do Y” — “If it’s global or domain-wide → do Z.”

The hardest part of state management isn’t picking a library. It’s having the courage to say ‘no’ to everything that doesn’t fit your agreed rules.

The Unsexy Advice: Start Simple, Then Add Structure When Reality Demands It

If you’re architecting a big Angular project today, here’s the boring, high-leverage path most experienced people quietly recommend:

Start with services + Signals for most state.
Add SignalStore when: — state is shared across multiple features, — you feel the pain of duplication and inconsistency.
Keep classic NgRx in existing apps where it’s already working; don’t rip it out proactively.
Resist the urge to “frameworkize” everything on day one.

You will be wrong about some decisions.

You will refactor some state flows later.

But you will be wrong based on real usage , not based on theoretical arguments in a meeting.

Scalability is not born from choosing the perfect state library. It’s born from making simple decisions consistently, and being willing to refactor when reality proves you wrong.

I fix the Angular apps that generalists break.

I’m Karol Modelski, senior Angular developer and frontend architect rescuing legacy B2B SaaS frontends.

If your Angular app is slowing your team down, start with a 3‑minute teardown of your current setup: https://www.karol-modelski.scale-sail.io/

Stop Complaining About Boilerplate: Why Angular’s Structure Is an AI Superpower

Karol Modelski — Thu, 04 Jun 2026 08:00:00 +0000

For years the joke has been:

React is “simple and flexible.”
Angular is “bloated” and “full of ceremony.”

Then AI coding tools showed up.

And suddenly, the framework everyone mocked for having too many rules started to look like the one best aligned with how LLMs actually work.

Because here’s the uncomfortable truth:

LLMs don’t understand your app. They pattern‑match.

The more predictable the patterns, the better they perform.

And Angular is nothing if not predictable.

In an AI-assisted world, Angular’s ‘rigidity’ stops being a burden and becomes a map the model can actually follow.

Why AI Struggles More With Chaos Than With Ceremony

Language models are not magical architects.

They’re probability machines trained on:

code examples,
docs,
tutorials,
open-source projects.

They do best when:

file locations are predictable,
naming conventions are consistent,
the framework has “one obvious way” to do something.

That’s exactly what opinionated frameworks give them. Articles about AI and opinionated stacks point out: when there’s a single, well-defined way to structure routes, components, and services, AI can reproduce useful patterns far more reliably.

Angular leans hard into:

components, services, DI, and modules/standalone structure,
TypeScript first,
clear, documented best practices.

React, by contrast, is deliberately flexible:

no single enforced folder structure,
multiple competing state patterns,
dozens of meta‑framework and library combinations.

That’s great for human experimentation.

It’s not great for a model that’s trying to guess “how this project probably works” based on partial context.

AI doesn’t get confused by ceremony. It gets confused by ten different patterns that all claim to be ‘the React way’.

Angular’s Opinionated Defaults Are a Feature, Not a Bug, for LLMs

Angular’s “heavy” structure gives AI a narrower search space :

components live in obvious places,
services follow DI patterns,
routing is standardized,
forms, HTTP, and state have blessed approaches.

Angular devs working with AI are already noticing this:

“Organized frameworks tend to be more user‑friendly with AI. When a framework presents one well‑defined approach, AI can replicate it precisely.”
“Angular’s modules, components, services and DI create a cohesive map models can follow more easily.”

On top of that, Angular now ships official AI guidance :

a best‑practices prompt file for LLMs that spells out how to structure components, signals, templates, services, and accessibility.
guidance like: — use standalone components, — use signal()/computed() for state, — prefer inject() DI, — use new control flow, — keep components small and focused.

You can literally feed this document into your AI tooling as system instructions so it knows the rules beforehand.

Contrast that with “just React”:

AI must first infer whether you’re using CRA, Vite, Next.js, Remix, a custom setup, or something else entirely.
Then it has to guess your state approach, routing, file layout, and styling stack.

Angular doesn’t just give humans conventions. It gives AI a contract: ‘If you follow these rules, you will probably generate code that fits.

Why Angular’s “Boilerplate” Becomes a Turbocharger With AI

All the things people call “boilerplate” in Angular?

They’re actually signal beacons for AI:

Predictable file naming and structure

— *.component.ts, *.service.ts, *.directive.ts, etc.

— Easy for tooling and LLMs to locate and extend.
TypeScript everywhere

— models, interfaces, enums, generics.

— static types give models strong hints about what goes where and how to call it.
Built‑in patterns for services and DI

— providedIn: ‘root’, inject() usage, clear service responsibilities.
Standardized Angular CLI + schematics

— Angular and Nx schematics encode best practices; AI can mimic them or call them safely.

Developers are already using AI like a supercharged ng generate:

“Create a component with these inputs/outputs and these services,” then let AI fill in wiring and boring glue.
let AI write form controls, validation, basic templates, while the human focuses on flows and architecture.

In one LinkedIn post, a dev described Angular + AI like this:

predictable structure is “a well-drawn map,”
TypeScript is “gold” for AI,
modularity helps AI focus on small pieces,
CLI & schematics standardize code so AI can generate consistent snippets.

The more ‘ceremonial’ the framework, the more surface area AI has to latch onto and the less creative guessing it has to do.

React’s Flexibility vs Angular’s Rigidity in an AI World

None of this means React is “bad” with AI.

In fact:

React and Next.js currently get more AI‑optimized examples and templates, which is why many tools default to them.
There’s more open-source React training data overall.

But there’s a split emerging:

LLM performance at “toy” and prototype scale

— AI tools default to Next.js/React for quick landing pages, dashboards, and demos, because the ecosystem around them is heavily tuned for that.
LLM reliability at “actually complex” app scale

— devs observe that Angular’s strict structure reduces the range of bad options the AI can pick in large codebases.

One discussion summed it up neatly:

the stricter the framework, the fewer random patterns AI will invent,
the more flexible the framework, the more ways AI can accidentally make a mess unless the human is very opinionated.

That maps perfectly onto what we already know:

Angular’s defaults reduce accidental inefficiencies and guard rails teams into safer patterns.
React offers a higher performance and flexibility ceiling — but only if the team enforces their own conventions.

Now add AI:

in Angular, AI tends to color within well-defined lines,
in React, AI can accidentally mix styles, patterns and libraries drawn from a noisy training set.

AI doesn’t care about your identity as a ‘framework person.’ It cares about how easy it is to predict where things go — and Angular hands it that predictability.

Angular + AI: From Vibe Coding to Agentic Workflows

The real future isn’t “AI writes all your code.”

It’s agentic workflows — AI assistants that understand your repo, follow your rules, and act like junior devs embedded in your architecture.

Angular is already leaning into that:

official docs on “develop with AI” and prompt files tailored for Angular repos;
workshops teaching advanced Angular devs how to integrate AI in a traceable , policy‑driven way (not just copy‑paste vibe coding);
guidance on using Angular’s strict mode, linting, Nx, and style guides as guardrails for both humans and AI.

That means you can:

plug in AI agents that respect your module boundaries and coding standards,
let AI propose refactors, add tests, or modernize code (standalone components, Signals, new control flow) while you review diffs,
keep a clear audit trail of what changed and why.

In other words:

Angular provides the rails; AI supplies the acceleration.

Without those rails, AI is just as likely to:

split logic randomly across files,
pick inconsistent state solutions,
or introduce subtle bugs under the banner of “productivity.”

Angular’s rigidity isn’t about gatekeeping humans. It’s about giving both humans and AI a structure where their speed doesn’t devolve into chaos.

The Thesis: Angular Is Quietly Future‑Proof in an AI World

If you’re an Angular dev, you’ve probably spent years defending your framework against:

“too heavy,”
“too much boilerplate,”
“too opinionated.”

AI flips that narrative.

In a world where:

tools generate huge chunks of code,
assistants refactor entire modules,
agents run in your CI and IDE,

the frameworks that win are:

strict enough that AI can’t go completely off the rails,
structured enough that teams can reason about AI‑driven changes,
typed and patterned enough that suggestions line up with reality.

That describes Angular almost perfectly.

So the next time someone tells you:

“Angular is too rigid,”
“we should use something simpler,”
“AI works better with flexible frameworks,”

remember:

AI doesn’t want freedom. It wants structure. Angular gave you that structure years before AI showed up — and now that ‘boring’ choice looks like one of the most future‑proof bets you could have made.

I fix the Angular apps that generalists break.

I’m Karol Modelski, senior Angular developer and frontend architect rescuing legacy B2B SaaS frontends.

If your Angular app is slowing your team down, start with a 3‑minute teardown of your current setup: https://www.karol-modelski.scale-sail.io/

Your AI Assistant Is a React Fanboy and You Should Be Worried

Karol Modelski — Thu, 28 May 2026 08:00:00 +0000

Ask most AI coding tools to “build me a web app” and watch what happens.

Nine times out of ten, you’ll get:

React,
Next.js,
Tailwind,
maybe a sprinkle of popular auth and UI libraries.

No context.

No questions about your team.

No questions about your constraints.

Just React‑by‑default.

If you listen to AI long enough, you could easily conclude:

React is obviously the “right” choice,
Next.js is obviously the framework for everything,
Angular is for… nobody, apparently.

AI doesn’t pick stacks based on your reality. It picks stacks based on its training data — and that’s not the same thing.

Why AI Tools Keep Recommending React and Next.js

This isn’t a conspiracy.

It’s a side effect of how these models learn and how AI builders integrate frameworks.

A few reasons:

Training data dominance

Public React and Next.js codebases, tutorials, templates, and snippets massively outnumber public Angular projects.

Many Angular apps live in closed enterprise repos, so models simply see less Angular.
Tool vendor choices

Firebase Studio, no‑code builders, AI prototyping tools — many officially support Next.js as their first or only framework and plan to “add others later.”

That means AI integrations, examples, and docs are tailored for that stack.
AI optimization efforts

Some companies are literally optimizing React/Next.js code for AI use, publishing curated “best practices” repos tuned for model consumption.
Ecosystem momentum

AI‑friendly tutorials, AI‑generated starter kits, and vibe‑coding demos on YouTube skew heavily toward React + Next.js.

So when you throw a vague prompt like:

Build a SaaS dashboard with user auth, billing, and admin controls

into an AI assistant, the model defaults to the pattern it has seen the most:

React + Next.js. Not because your problem needs it — because the internet is full of it.

AI isn’t your architect. It’s a statistical mirror of what everyone else already did — mostly with React.

When Letting AI Choose Your Stack Actively Hurts You

For small demos or personal projects, React/Next.js as a default is fine.

For serious systems, blindly following AI’s bias can backfire hard.

Examples of where this goes wrong:

Your team is mostly Angular or .NET people

The AI happily scaffolds a React/Next.js app because it looks “modern.”

Now your entire team has to:

— learn a new mental model,

— rebuild internal patterns,

— juggle two ecosystems.
You’re building a long‑lived enterprise product

React’s flexibility is great short‑term. Long‑term, it demands discipline, conventions, and extra libraries to get the “framework” behavior Angular gives you out of the box.

AI doesn’t know how disciplined your team is.
You need consistency across multiple teams and services

Angular’s opinionated structure often makes multi‑team maintenance easier over years. React’s “assemble your own framework” dynamic amplifies inconsistency when different squads pull in different stacks and patterns.

Yet AI will almost never ask you:

“How many teams will work on this?”
“What’s your current stack?”
“Who will maintain this in 3–5 years?”

It just picks the thing it has been trained to spit out confidently.

Letting AI choose React for your team because ‘that’s what it generated’ is like letting Google autocomplete decide your system architecture.

The New Villain: AI Bias in Tech Stack Selection

The Angular vs React fight is old.

The new villain is the invisible bias sitting inside AI tools.

We’re already seeing developers point out that:

AI agents tend to “suck with Angular” — they hallucinate APIs, ignore DI, and fight the framework instead of using it correctly.
React and Next.js feel “more AI‑friendly” because models have more examples and clearer integration paths.
People gravitate toward stacks where AI “feels better,” even if it’s not better for their project.

This creates a loop:

AI works better with React/Next.js →
More people choose React/Next.js because AI feels smoother →
More React/Next.js code goes into training data →
AI becomes even more biased toward React/Next.js.

Angular gets squeezed out of AI’s “comfort zone,” despite remaining incredibly strong in exactly the kinds of systems AI is bad at reasoning about: long‑lived, multi‑team, enterprise apps.

The danger isn’t that React wins. It’s that AI quietly removes Angular from the menu before the humans even sit down.

“Most Popular” Is Not the Same as “Most Productive for You”

Stack Overflow surveys and GitHub stars show React still leads in usage.

But that does not automatically mean:

React is the most productive for your team,
React is the best choice for your domain,
React + Next.js is the right default for AI-assisted development in every case.

Developers with experience in both stacks keep reporting:

Angular is often easier to maintain long‑term when teams and requirements change, because it gives you structure and consistency.
React is often nicer to write in for small to medium projects, especially for solo devs or startups.

For AI‑heavy frontends:

React has more AI‑tailored component libraries and examples , especially for chat UIs and dashboards.
Angular offers better enterprise integration , type safety, and form handling for complex, bureaucratic systems.

The key point:

AI is biased toward what is most common and most explicitly optimized for it, not what fits your team and your business.

If you confuse ‘most popular in the training data’ with ‘most productive for my context,’ you’re letting statistics, not strategy, run your stack.

Why I Would Still Return to Angular After AI Pushes Next.js

AI tools love Next.js as the “structured React default.”

For a lot of quick prototypes and SaaS frontends, that makes sense.

But if:

the project will live 5+ years,
multiple teams will touch it,
you care about strict types, form complexity, and consistency,

there are still many cases where I would actively steer back to Angular — even if AI keeps demoing Next.js.

Reasons:

Opinionated architecture

— less “choose your own adventure” in folders, state, routing, and DI,

— easier onboarding when devs come and go.
Enterprise alignment

— Angular’s model aligns with how a lot of larger organizations actually work — modules, teams, domains, shared libraries.
Consistency over time

— fewer wild swings in patterns every six months,

— less chance of a Frankenstack assembled from every hot React meta‑framework.

Does that mean Angular is “objectively better”?

No.

It means AI’s default suggestion is not a substitute for thinking about the lifecycle of your system.

AI can scaffold your first month. It doesn’t have to live with your third year.

How to Use AI Without Letting It Pick Your Stack for You

You don’t need to fight AI.

You just need to move stack selection back where it belongs: human judgment.

Practical steps:

1. Decide the stack before you touch AI

Start from constraints:

team skills,
existing systems,
lifespan of the project,
regulatory and scalability needs.

Pick a stack from that, then tell AI:

We are using Angular here. Follow Angular best practices and do not switch frameworks.

or:

This company is a React shop. Use React, not Next.js, unless I explicitly ask.

2. Be explicit about “no stack switching”

AI assistants will happily suggest migrations:

“We could move this to Next.js for better SEO.”
“Let’s use this React library; it’s more popular.”

Shut that down early:

“Do not propose changing the main framework. Work within Angular.”
“Respect the existing tech stack; no rewrites unless explicitly requested.”

3. Feed it your own patterns

If you want AI to be less React‑biased:

give it Angular examples from your codebase,
show it your module, state, and component conventions,
ask it to follow those patterns.

You’re not going to overpower global training data, but you can tilt its answers toward your reality.

4. Separate “AI for scaffolding” from “AI for architecture”

Use AI for:

components,
forms,
tests,
boilerplate.

Do not outsource:

domain modeling,
system boundaries,
long‑term architecture choices.

AI should fill in code inside a decision, not make the decision for you.

The Real Takeaway: AI Reflects the Crowd, Not What’s Right

AI is not secretly on React’s payroll.

It is doing exactly what it was designed to do:

approximate the most likely answer,
based on the data it has seen the most.

Right now, that means:

React and Next.js for most “build me an app” prompts,
Angular often underrepresented despite its strength in enterprise.

If you know this and act accordingly:

AI becomes a useful power tool inside whatever stack you intentionally choose.

If you don’t:

AI becomes a quiet, persuasive force pushing every problem toward the same default stack — whether it fits or not.

Your AI assistant is a React fanboy by training. Your job is to be the adult in the room who knows when that bias is helping you and when it’s quietly wrecking your architecture.

I fix the Angular apps that generalists break.

I’m Karol Modelski, senior Angular developer and frontend architect rescuing legacy B2B SaaS frontends.

If your Angular app is slowing your team down, start with a 3‑minute teardown of your current setup: https://www.karol-modelski.scale-sail.io/

Why Prompt Engineering Is Just an Expensive Way to Be Incompetent

Karol Modelski — Thu, 21 May 2026 08:00:00 +0000

Watching some people “use AI at work” has convinced me of one thing:

AI is not replacing competent developers any time soon.

But it is doing a fantastic job of exposing who didn’t really know what they were doing in the first place.

You’ve probably seen this pattern already:

50 prompts.
20 rewrites.
Endless “make it more robust / more scalable / more production-ready” messages.
Zero understanding of what’s actually happening.

Meanwhile, a real developer could have:

understood the problem,
written a small, clear solution,
and finished in one or two focused passes.

Prompt engineering doesn’t magically turn non-technical people into builders. It mostly turns their confusion into very expensive text.

The Claude Credit Summary That Made Me Feel Weirdly Safe

Everyone talks about AI as an existential threat.

Then you open your team’s or company’s usage dashboard and see something like:

thousands of credits burned on trivial tasks,
long chat sessions where the same vague question is rephrased 20 times,
reports and docs generated, then manually rewritten for hours.

You realize:

The people most excited about “prompt engineering” are often the ones who never learned how to think like engineers.

Real examples companies are already sharing:

managers spending hours correcting AI-generated reports that “took 5 minutes,” creating what some call prompt engineering debt—a new layer of work on top of already busy jobs;
no-code builders burning hundreds of credits a day because they keep asking vague questions instead of clarifying requirements or reading basic docs;
teams running complex tasks on the most expensive models when cheaper ones (or a quick human fix) would have done the job.

Meanwhile, controlled studies keep saying the same thing:

AI coding assistants give big gains in some contexts,
and outright slow developers down in others—especially when tasks are small or the codebase is well understood.

If you need 30 prompts to get what a competent dev would produce in one shot, the problem isn’t that you need ‘better prompting techniques.’ The problem is you don’t know what you’re asking for.

“Prompt Engineering” vs Actual Engineering

Prompt engineering was briefly sold as a new job category:

no code,
no math,
no systems thinking,
just “talk well to the model.”

Companies are already walking that back.

The emerging consensus:

“prompt engineer” as a standalone role is fading;
what’s valuable now are people who understand systems, data, constraints, and verification—and happen to use AI well.
In other words:
AI skills are a multiplier on real expertise,
not a replacement for the expertise.
The difference in practice:
A non-technical “prompt engineer” burns tokens asking the model to invent APIs, architectures, and glue code from scratch.
A real developer feeds the model context, constraints, and code, then uses it to refactor, scaffold, or check specific parts.

Prompt engineering without domain knowledge is just creative ways to waste money faster.

The Hidden Inefficiency: Prompt Engineering Debt

People talk about technical debt.

We’re now accumulating prompt engineering debt:

AI-generated docs that sound authoritative but are subtly wrong,
half-baked scripts or UIs that “mostly work” but hide security or performance issues,
workflows no one can reproduce because the steps lived entirely inside chat logs. You save 10 minutes by letting AI draft something.

You lose:

hours verifying, correcting, and reformatting,
more hours when future you or someone else has to figure out “how this was made,”
trust, when stakeholders discover the tool hallucinated key details.

Managers and non-technical leaders are already reporting:

AI “helped” them finish something fast,
but they then spent several hours fixing it,
net result: more tired, not more productive.

This is the real cost nobody includes in their “AI saved me X hours!” posts.

AI doesn’t just create output. It creates obligations: to verify, to correct, to own the result. Prompt debt is still debt.

Watching a Prompt Power User Struggle With a Two-Minute Bug

The most painful demos of “AI superusers” often look like this:

They hit a bug or small logic issue.
Instead of reading the code or error message, they:
- paste everything into Claude or another model,
- ask it to “fix the problem,”
- get a large diff,
- apply it blindly,
- break something else.

Repeat.

If you’re an actual developer, you know what a normal path looks like:

read the error,
follow the stack trace,
inspect inputs and outputs,
change one or two lines,
add a test if needed.

Two minutes.

The “prompt engineer” route:

20+ minutes and 100+ credits,
three or four different attempts,
unsatisfying sense that “it works now but not sure why.” This is not AI’s fault.

This is what happens when someone:

doesn’t understand the system,
doesn’t trust themselves to reason about it,
and thinks more prompting is always the answer.

If AI is your first reflex for every tiny issue, you’re not a power user. You’re outsourcing your thinking.

Being an AI Superuser Is Not the Same as Being a Developer

There is such a thing as an AI power user.

They look nothing like the people throwing 400-line prompts at every problem.
Real power users:

have solid fundamentals in at least one domain (dev, data, ops, product),
use AI to compress workflows they already understand,
treat models as tools in a chain, not as all-knowing oracles.

They:

script repeated tasks,
integrate AI into editors, terminals, and CI pipelines,
design small, reliable loops where the model does the mechanical parts.

They do not:

spend all day rewriting the same vague prompt,
rely on AI to invent systems they don’t understand,
brag about number of tokens used as if that were a productivity metric.

Being good with AI is not about ‘talking to it a lot.’ It’s about knowing enough to ask for the right thing once.

The Ego Layer: Prompt Engineering as a Mask for Insecurity

Here’s the uncomfortable part:

For some people, “prompt engineering” is a socially acceptable way to hide insecurity.

Instead of saying:

“I don’t understand this system,”
“I need to learn the basics,”
“I’m out of my depth,”

they say:

“I’m working on AI workflows,”
“I’m refining the prompt,”
“The model just needs better instructions.” It sounds sophisticated.

It keeps them in the conversation.

It lets them avoid asking the “stupid questions” they really need to ask.

But underneath that layer of AI jargon, nothing changes:

no better mental models,
no better debugging skills,
no better understanding of trade-offs.

Prompt engineering becomes a costume you wear so people don’t see that you’re scared to admit what you don’t know.

How Skilled Developers Actually Use AI (and Why That’s Threat-Proof)

Most senior devs who integrate AI deeply share the same pattern:

They use AI to:

accelerate things they already know how to do,
generate first drafts they fully understand and can rewrite,
explore alternatives or edge cases they might have missed.

They don’t:

let AI design the architecture of a system they don’t understand,
push AI-generated changes without reading them carefully,
use AI as a shield from having to think.

Studies and field reports show:

AI assistants give big boosts when engineers know their stack and use AI as an exoskeleton;
in unfamiliar systems or without clear specs, they can slow things down or create new failure modes.

The job that’s safest long-term is still:

understanding systems,
making decisions under uncertainty,
reviewing and owning the output—human or AI-generated.

The thing that keeps you safe is not how many prompts you can write. It’s how many decisions you can own.

If You’re Technical: Why This Whole Trend Should Calm You Down

If you’re a real engineer worried about AI replacing you, look carefully at how most “prompt superusers” actually work today.

You’ll see:

a lot of noise,
a lot of wasted tokens,
a lot of shallow output,
and a lot of work created for the people who still have to be accountable.

The market is already correcting:

the hype around “prompt engineer” as a standalone role is fading;
companies are hiring for AI + X (engineering, data, product, security), not for “AI whisperers”;
senior developer roles are shifting toward more design, review, integration, and governance—not away from them.

AI will absolutely replace:

a chunk of low-skill work,
some tasks that used to justify junior roles,
a lot of fake productivity.

It will not replace:

clear thinking,
system-level understanding,
the ability to define what “good” looks like in the first place.

Your job is not to compete with people burning credits. Your job is to be the person who knows what should happen before anyone opens a chat window.

I fix the Angular apps that generalists break.

I’m Karol Modelski, senior Angular developer and frontend architect rescuing legacy B2B SaaS frontends.

If your Angular app is slowing your team down, start with a 3‑minute teardown of your current setup: https://www.karol-modelski.scale-sail.io/

AI Isn't Replacing Developers - It's Turning Us Into Underpaid Bot Babysitters

Karol Modelski — Thu, 14 May 2026 08:00:00 +0000

The future of engineering was supposed to look like this:

AI handles the boring stuff.
Humans focus on architecture, hard problems, and product.

What it often looks like instead:

juniors (and some seniors) blasting Claude or other LLMs with vague prompts,
copy‑pasting whatever comes out into massive PRs,
you spending your week diff‑diving, untangling “AI slop,” and explaining basic trade‑offs in code review.

The robots didn’t take your job.

They just turned you into an underpaid bot babysitter.

AI didn’t automate away my work. It automated the creation of bad work and left me responsible for all of the cleanup.

Meet the “Vibe Coder”: Shipping PRs by Feel, Powered by LLMs

Every team now has at least one vibe coder.

You know the profile:

never reads the existing codebase deeply,
never asks about architecture,
but can generate 1,000+ lines of “looks impressive” code in an afternoon.

Their workflow:

Paste a ticket into Claude / another LLM.
Get a wall of code, tests, and maybe even docs.
Lightly tweak variable names.
Open a PR with a confident description: ""

"Implementing X feature with full test coverage."

From the outside, it looks like high output:

lots of commits,
lots of lines changed,
lots of green checkmarks when basic tests pass.

On the inside, you see:

duplicated logic the model invented because it didn’t see existing utilities,
inconsistent patterns across modules,
subtle bugs around edge cases, error handling, security.

Vibe coding is when the code ‘feels’ right because the diff is big and the AI sounded confident, but nobody actually sat down to think.

AI Sludge as a New Form of Tech Debt

People talk about “AI slop” like it’s just ugly code.

It’s bigger than that.

We’re seeing patterns like:

Code duplication explodes – analyses show AI‑assisted code can double duplication and dramatically reduce refactoring.
Maintainability drops quietly – LLM‑generated code may pass tests and even have fewer obvious bugs, but hides structural issues and unnecessary complexity.
Surface‑level quality looks fine – style, docs, and naming look better… right up until you try to change anything non‑trivial.

Open source maintainers are already burning out from a flood of low‑effort AI PRs that:

don’t solve real issues,
add generic utilities that already exist,
introduce subtle bugs for marginal gains.

Inside companies, the same dynamic is happening:

more code, more diffs, more “AI‑accelerated” changes,
without any corresponding increase in architectural thinking.

AI is building a new class of tech debt: everything looks modern and well‑typed until you try to evolve it, and then the whole thing fights back.

The Senior’s New Job: AI Janitor, Therapist, and Politician

If you’re mid/senior, you’re probably seeing your role drift:

less time building systems,
more time reviewing, rejecting, and explaining AI‑generated changes.

Your real job description becomes:

AI janitor – identify duplicated logic, unnecessary abstractions, and hallucinated APIs; refactor or rewrite them.
Code therapist – explain to enthusiastic AI‑power users why their 1,200‑line PR is not a “productivity win.”
Team politician – push back on leadership who only see output metrics and not the long‑term maintenance cost.

Meanwhile, company narratives sound like:

“AI has doubled our feature velocity.”
“Look how many lines of code we’ve shipped this quarter.”

Nobody is tracking:

how many critical bugs came from rushed AI‑generated changes,
how much time seniors spend auditing vs building,
how much harder future projects become because the codebase is now stitched together by vibes.

We’re measuring AI success in story points and PR counts, and measuring human burnout in private 1:1s and late‑night Slack messages.

AI as a Corporate Politics Weapon

There is another uncomfortable layer to this:

AI tooling doesn’t just change code.

It changes office politics.

If you know how to:

generate polished architecture diagrams, long docs, and “vision” slides with AI,
push big, flashy PRs that look ambitious,
speak confidently about “leveraging LLM productivity,”

you can look like a star to non‑technical leadership.

Even if:

your changes are hard to maintain,
your “AI‑driven refactor” quietly destabilizes core flows,
senior engineers repeatedly warn about long‑term risk.

The people who:

optimize for perception,
“ship” with AI,
and keep talking about “innovation”

get rewarded.

The people who:

read the diff carefully,
ask annoying questions about edge cases,
block PRs that don’t meet standards,

get labeled as:

“slowing things down,”
“resistant to AI,”
“too negative.”

AI didn’t end office politics. It just gave the loudest people a way to generate more ‘evidence’ of their impact without doing more thinking.

Not All AI Code Is Bad — That’s What Makes This Hard

Here’s the twist:

Some studies show LLM‑generated code can have fewer obvious bugs and be easier to patch than human code for certain tasks.
Some leads argue they prefer “boring LLM output” over wildly inconsistent human code.

They’re not entirely wrong.

AI can be:

great at boilerplate,
consistent in style,
surprisingly solid on well‑scoped problems.

The problem is not “AI code = bad, human code = good.”

The problem is:

unskilled prompting + zero context + no review discipline + wrong incentives = sludge,
and we’re throwing that into complex systems that absolutely require someone to think several steps ahead.

AI can absolutely write decent code. But decent code, dropped thoughtlessly into a complex system, is still a bad change.

How to Stop Being a Bot Babysitter (Without Becoming a Dinosaur)

If you’re a senior developer, you don’t fix this by rejecting AI.

You fix it by setting constraints and changing the default workflow.

1. Make AI usage explicit, not sneaky

Require PR descriptions to state when AI was heavily used.
Normalize saying “AI assisted” instead of pretending everything came from pure genius.

This isn’t about shame. It’s about review expectations.

2. Raise the bar on review for AI-heavy PRs

Smaller, focused PRs over giant “AI dump” diffs.
Require tests that demonstrate understanding, not just generated snapshots.
Explicit rationale for architectural decisions, not just “the model chose this.”

3. Build a checklist for AI‑generated code

Teams and maintainers are already doing this:

check for duplication (search for repeated blocks across the repo),
check for existing utilities the AI ignored,
check for security issues and edge cases,
check integration points instead of just local correctness.

Automate what you can:

linting, duplication detection, basic structural checks.

4. Train people to use AI like an engineer, not a copier

start from the existing architecture, not from a blank prompt,
use AI to propose variations, not final answers,
require devs to explain any AI‑generated code in their own words during review.

If someone can’t explain it, they don’t merge it.

The goal isn’t to stop AI writing code. It’s to stop people from outsourcing their thinking and calling it productivity.

If You’re a Senior: Redefine Your Job Before Someone Else Does

AI is not going away.

Companies will keep buying tools and pushing for “higher productivity per engineer.”

You have a choice:

be the burned‑out reviewer who cleans up after everyone,
or be the person who designs how AI fits into the engineering process.

That looks like:

owning guidelines for AI‑assisted coding,
building or choosing tooling that catches obvious AI‑slop,
mentoring your team on using models as partners, not crutches,
educating leadership on the difference between velocity and sustainable delivery.

Long term, the people who win are not:

anti‑AI gatekeepers,
AI‑only “vibe coders.”

It’s the ones who can:

think clearly,
architect systems,
leverage AI responsibly,
and protect the codebase from looking productive while decaying inside.

AI will not replace you. But someone who understands both engineering and AI—and refuses to be a quiet janitor—absolutely can.

I fix the Angular apps that generalists break.

I’m Karol Modelski, senior Angular developer and frontend architect rescuing legacy B2B SaaS frontends.

If your Angular app is slowing your team down, start with a 3‑minute teardown of your current setup: https://www.karol-modelski.scale-sail.io/

AI Is Turning My $5,000 Freelance Projects Into $500 Tasks

Karol Modelski — Thu, 07 May 2026 08:00:00 +0000

A few years ago, a simple CRUD app, a marketing site, or an internal dashboard could easily justify a $5,000+ freelance invoice.

Scoping, architecture, implementation, testing, iteration—it took weeks.

Clients accepted that.

Now?

You open Claude Code or Cursor, describe the app in a paragraph, and in a single afternoon you can have a working MVP with authentication, CRUD, and deployment scripts.

And suddenly your brain asks a brutal question:

“How can I charge $5,000 for something I can now build in two hours without feeling like a fraud?”

"AI didn’t just speed up my work. It detonated the mental model that my time and effort were the basis of my pricing."

The Efficiency Paradox: When Getting Faster Makes You Feel Cheaper

On paper, AI coding tools should be amazing for freelancers:

higher productivity,
faster delivery,
more projects per month.

In reality, they create a paradox:

if you keep charging by the hour, your income gets crushed;
if you charge by the project, you feel like you’re overcharging because “it only took a day with AI.”

Meanwhile:

clients are reading case studies about people building full platforms with Claude in a few weeks instead of six months with agencies;
non-technical founders are using AI to do work they previously outsourced to freelancers entirely.

The result?

The middle of the freelance market starts to hollow out:

low-end clients go straight to AI or to the cheapest “script kiddie” using AI badly;
high-end clients still pay well—but only for people who can handle strategy, architecture, and risk, not just raw implementation.

"AI didn’t erase the need for developers. It erased the justification for mediocre, effort-based pricing."

Why Value-Based Pricing Suddenly Feels Like a Lie

For years, the advice was simple:

“Don’t charge by the hour. Charge based on value.”

That made sense in a pre-AI world where:

your expertise was the main speed multiplier,
your time and effort were visibly linked to the outcome.

In the AI era:

you can build in days what used to take weeks;
you can ship in hours what used to be “two sprints.”

That’s good for the client, but psychologically brutal for you:

quoting $5,000 for something you can build in a day feels like a scam,
quoting $1,000 feels “fair” but destroys your ability to run a business,
going back to hourly rates gets you compared directly to cheaper devs and AI.

The real problem:

You are still anchoring your price on effort in your head, even while trying to talk about value in your proposal.

Your brain knows:

“This took me 10 hours with AI, not 60.”
So it quietly marks down what you feel allowed to charge.

Clients, meanwhile, don’t care about your hours. They care about:

how much risk you remove,
how much faster they go to market,
how much revenue or efficiency your solution actually creates.

"The fraud feeling doesn’t come from value-based pricing. It comes from secretly pricing your self-worth in hours while pretending you don’t."

What Clients Are Actually Paying For (Hint: It’s Not Code Lines)

Look at how serious buyers pay for AI work today:

experienced AI devs charge $75–$200+ per hour because they reduce risk and move faster, not because they grind more hours;
AI agent platforms charge based on value metrics—tasks completed, SLAs hit, revenue lift—not just compute.

The pattern is the same for freelancers who survive this shift:

Clients are paying for:

Risk reduction

You stop them from wasting six months on the wrong architecture, wrong feature set, or wrong vendor.
Clarity and decision-making

You turn vague ideas into actionable scopes, MVPs, and roadmaps. AI doesn’t sit in stakeholder calls and push back on bad requirements.
Integration and ownership

You connect AI-built pieces to real systems: auth, billing, compliance, infrastructure, observability.
Trust and accountability

You are there when something breaks. You maintain, adapt, and iterate. AI is a tool, not an owner.

The code is becoming commoditized.

The outcome and risk management are not.

"Freelancers who keep selling code as if it’s scarce will feel undercut. Those who sell outcomes and risk reduction will feel in demand."

The Script Kiddie Problem: When AI Makes Amateurs Look “Good Enough”

Claude, Copilot, Cursor, and every other assistant just gave every beginner a temporary superpower:
They can:

scaffold apps,
glue tutorials together,
and produce surprisingly decent demos.

To non-technical clients, that looks “close enough” to what you do—especially on small projects.

Why pay $5,000 when:

someone on Upwork offers $500,
or the client can brute-force something with AI for the cost of a subscription?

This is where the middle gets hollowed out:

if your positioning is “I build websites / CRUD apps / dashboards,” you are now interchangeable with AI‑assisted juniors;
the top of the market—complex systems, serious budgets, strategic work—is still there, but requires a completely different pitch.

The uncomfortable truth:

AI has lowered the bar for “good-enough output,” so only being “technically competent” is no longer enough to justify mid-to-high freelance pricing.

"The script kiddie with Claude is not your direct competitor. Your real competitor is your own refusal to move up the value chain."

How to Price in the AI Era Without Feeling Like a Fraud

If you want to keep charging real money while using AI, you need to change what’s on the invoice.

You can’t just write:

“Web app development – 40 hours”

and secretly know it took 8.

You need offers that make sense even when the work is fast.

Think in terms of packages and outcomes, not tasks:

Discovery + design + implementation
- Clarify the problem, run a strategy workshop, define success metrics, then build the MVP—with AI as your power tool.
MVP in 2 weeks, validated with users
- You are not selling screens. You are selling “a thing we can put in front of customers in two weeks and learn from.”
Migration / modernization
- Move a legacy system to a new stack, keep data safe, minimize downtime, and document everything. AI accelerates—but the risk is still real.
AI integration / automation
- Connect their existing tools, build agents or workflows, and own the reliability and monitoring.

Price for:

the risk you’re taking on,
the business impact,
the speed to a meaningful outcome—

not for the keystrokes.

"Value-based pricing only feels honest if the thing you’re selling is a value narrative, not a disguised time estimate."

Concrete Levers to Survive (and Win) the AI Pricing Crisis

Some practical shifts that move you out of the danger zone:

Rewrite your positioning

Replace “I build X with Y framework” with:

“I help [niche] achieve [business goal] with software and automation.”

Show your thinking, not just your builds

Share teardown threads, architecture breakdowns, “here’s why this approach works.”

That’s how you signal that clients are buying your brain, not just your typing speed.

Sell productized services

Example packages:

“MVP Launch Week”
“Analytics & Automation Audit”
“Migration Risk Assessment + Plan”

Clear scope, clear outcome, fixed price.

Lean into AI visibly, not secretly

Tell clients:

“Yes, I use AI heavily—that’s how I move fast. You’re paying for knowing what to build, what to trust, and how to keep it alive.”

Keep a floor on your pricing

If you drop to $300 projects “because AI made it easy,” you are training the market—and yourself—to believe your work is cheap.

"The freelancers who survive are not the ones who hide AI. They’re the ones who can explain why using AI makes them even more worth the money."

The Future: Fewer Freelancers, Stronger Positions

Generative AI is absolutely reshaping the freelance market.

Studies already show: some segments of digital freelancing see collapsing demand as clients use AI or in-house tools instead. At the same time, specialized AI and software freelancers at the top end are charging more because they’re tied to high-impact work.

The likely outcome:

fewer freelancers doing generic implementation work,
more freelancers:
- embedded as fractional CTOs / product leads,
- owning automation and AI workflows,
- selling consulting + implementation bundles.

If you insist on:

billing by the hour,
marketing yourself as “a pair of hands,”
competing with whoever is cheapest + AI,

the AI pricing crisis will feel like a slow suffocation.

If you:

move up-market,
sell outcomes and risk reduction,
and treat AI as your exoskeleton,

you can absolutely justify $5,000 (or more) while building faster than ever.

"AI is not killing value-based pricing. It’s killing lazy value stories that were secretly still about hours. The rest of us now have to grow up."

I fix the Angular apps that generalists break.

I’m Karol Modelski, senior Angular developer and frontend architect rescuing legacy B2B SaaS frontends.

If your Angular app is slowing your team down, start with a 3‑minute teardown of your current setup: https://www.karol-modelski.scale-sail.io/

Your Perfectionism Is Killing Your Career Before It Even Starts

Karol Modelski — Thu, 30 Apr 2026 08:00:00 +0000

A lot of self-taught developers think perfectionism is a virtue.

You obsess over:

the “right” folder structure,
the “cleanest” abstraction,
the “correct” testing strategy for a to‑do app you never ship.

Underneath that, there’s usually one thing:

a brutal, silent fear of being judged.

So you keep polishing, keep refactoring, keep “learning more” instead of showing your work to real people.

"Perfectionism feels like a high standard. Most of the time, it’s just fear wearing a respectable outfit."

The Self-Taught Developer’s Loop of Death

If you’re self-taught, your path probably looks like this:

binge tutorials,
start side projects,
never finish them,
because “they’re not good enough yet.”

You tell yourself:

“I’ll start freelancing when I’m better.”
“I’ll take clients when I’m sure I won’t embarrass myself.”
“I just need one more course before I’m ready.”

Meanwhile:

your GitHub is full of half-finished repos,
your portfolio has three “coming soon” sections,
your confidence is shrinking, not growing.

You are not gaining:

real feedback,
real constraints,
or real trust in your abilities.

You are just getting better at learning in the dark.

"You’re not stuck because you’re underqualified. You’re stuck because you refuse to be seen as anything less than perfect."

Clients Do Not Want Perfect Code

There is one thing you need to internalize if you ever want to freelance:

Clients do not buy code. They buy outcomes.

They care about:

“Does this solve my problem?”
“Will this make or save me money?”
“Can I trust this person when something breaks?”

They do not care about:

whether your component composition is award‑winning,
whether your TypeScript generics are elegant,
whether your CSS is fully BEM‑compliant.

Most clients cannot even read your code. The ones who pretend to understand it are often just trying not to look ignorant.

And yet, you treat every tiny imperfection like a moral failure:

a missing edge case,
a messy function,
a bug that slipped through.

Here is reality:

every serious product ships with known imperfections,
most bugs get discovered in production anyway,
what matters is how fast you respond and how reliable you are.

"Clients aren’t looking for perfection. They’re looking for progress, responsiveness, and someone who takes responsibility."

Your Fear of Bugs Is Not Humility. It’s Ego.

This part hurts:

Most “fear of judgment” stories are not about humility.

They’re about ego.

You are not actually afraid that:

the app will be unusable,
the entire system will crash.

You are afraid that:

someone will think you’re not as good as you say you are,
a bug will expose that you are not “really a developer,”
your self‑image will crack.

So you:

avoid code reviews,
avoid shipping,
avoid freelancing conversations,
avoid showing your work to anyone who could say, “This isn’t perfect.”

That is not caution. That is self‑protection at the cost of your career.

Humility says:

“I will ship the best I can right now, and I’ll fix what breaks.”

Perfectionism says:

“If it’s not flawless, nobody is allowed to see it.”

Only one of those paths leads to becoming a professional.

"Refusing to ship until it’s perfect is not protecting clients from bad work. It’s protecting your ego from normal feedback."

Freelancing Is Not for Developers Who Wait for Perfection

Freelancing is a public sport.

You are constantly:

making promises,
making trade‑offs,
making mistakes where people can see them.

If your default state is:

“I will only take on clients when I’m sure nothing will go wrong,”

you will never start.

Because freelancing guarantees:

unclear requirements,
last‑minute changes,
weird edge cases in production,
tech you haven’t used before.

Clients don’t hire freelancers because everything is known.

They hire freelancers precisely when things are not clean and predictable.

Your job is not to guarantee perfection.

Your job is to:

listen carefully,
ship something concrete,
fix what breaks,
communicate like an adult.

"If you need a zero‑risk environment to function, freelancing will eat you alive. Ship, learn, adjust—or get out."

How to Break the Perfectionism Cycle and Actually Start

You do not beat perfectionism by reading more about perfectionism.

You beat it by shipping in ways that are structured to feel scary but survivable.

A few practical steps:

1. Lower the stakes on purpose

Stop making your first “public” project a full SaaS with subscriptions and multi‑tenant RBAC.

Instead:

build a tiny tool for a friend’s business,
ship a landing page with a contact form,
create one automaton (Zapier/n8n/Make) that saves someone an hour a week.

Smaller scope = smaller emotional explosion when something breaks.

2. Time‑box “polish loops”

Give yourself:

one pass for functionality,
one pass for obvious clean‑up,
then you ship.

Anything beyond that goes into a “V2 improvements” list.

3. Force feedback earlier

Do not disappear for weeks and then hope the client loves your “perfect” version.

Show:

ugly wireframes,
half‑done UIs,
basic flows that barely work.

Clients gain trust when they see progress, not when they see perfection after a long silence.

4. Define “good enough” before you start

Write this down per project:

must‑have: cannot ship without
nice‑to‑have: can wait for later
not‑now: explicitly excluded

If you have not defined this, your default will be “everything must be flawless,” and you will drown.

"The antidote to perfectionism isn’t carelessness. It’s defining clearly what ‘good enough to ship’ means before your feelings get involved."

Building a Professional Mindset: Progress Over Performance

Professionals don’t ship perfect work.

They ship work that:

solves a real problem,
is maintainable enough,
can evolve,
and improves over time.

They measure themselves by:

how quickly they turn feedback into improvements,
how well they communicate when things go wrong,
how consistent they are over months and years.

As a self‑taught dev, you have one huge advantage:

you are already good at learning on your own.

The missing piece is showing your work before you feel ready.

That is the muscle freelancing demands:

publish the portfolio, even if it’s not your dream aesthetic,
take a small client, even if you’re nervous,
send the invoice, even if your inner critic is screaming.

You will never fully “solve” fear of judgment.

You just become someone who ships anyway.

"Your career does not start the day you feel ready. It starts the day you’re willing to be seen as imperfect and still show up."

I fix the Angular apps that generalists break.

I’m Karol Modelski, senior Angular developer and frontend architect rescuing legacy B2B SaaS frontends.

If your Angular app is slowing your team down, start with a 3‑minute teardown of your current setup: https://www.karol-modelski.scale-sail.io/

TypeScript Complexity Has Finally Reached the Point of Total Absurdity

Karol Modelski — Thu, 23 Apr 2026 08:00:00 +0000

At some point over the last few years, TypeScript stopped being a tool and started becoming a performance art.

We went from:

“Let’s add types so we catch bugs earlier”

to:

“Behold my 80-line conditional type that nobody understands, including me.”

The worst part?

This is not a niche problem anymore.

If you work on modern web apps — Angular, React, Payload CMS, Nest, whatever — you have already opened a file where the types look like:

a PhD thesis in category theory,
accidentally minified,
and spread across five utility types imported from different packages.

Somewhere along the way, we quietly accepted that making our code unreadable was an acceptable side effect of ‘taking type safety seriously.’

When Type Safety Crossed the Line

TypeScript was supposed to do two things:

Make JavaScript less surprising.
Make refactors less terrifying.

Instead, in many codebases, it now does a third thing:

Makes every non-author terrified to touch the types at all.

This is especially visible in libraries and frameworks that want to impress other library authors more than they want to be usable by normal humans.

Think about patterns like:

deeply nested conditional types with multiple branches,
recursive mapped types that try to model an entire CMS schema and all possible query shapes,
overly clever generic constraints that explode into 20-line compiler errors if you look at them wrong.

Payload CMS types are a great example: extremely powerful, extremely expressive — and often borderline indecipherable unless you mentally expand half of the type tree. This is not unique to Payload; it is a pattern across many “pro” libraries in 2025.

We wanted guardrails. We ended up building a maze and calling it architecture.

The Hidden Cost of Type Gymnastics

Every time we ship a beautifully complex composite type, we pay a price that does not show up in the type system:

Cognitive overhead

New devs spend days decoding types instead of understanding the domain.
Debugging pain

Compiler errors point into nested conditional types with messages that read like algebra proofs.
Refactor paralysis

Nobody wants to touch core models because one wrong tweak to a generic breaks half the app’s inferred types.
Onboarding friction

Every new hire needs a private masterclass just to understand how types are wired. Until then, they are scared to change anything.

The irony: the more we optimize type cleverness, the less likely it is that anyone will have the courage to keep those types correct over time.

A type system that only one person understands is not a safety net. It’s a single point of failure.

Why We Got Here: Incentives and Ego

How did we end up with types that look like unreadable math equations?

A few predictable reasons:

Library ecosystem incentives

Library authors want strong “DX” stories and love to showcase magical inference that “just works.” Under the hood, that often means very heavy advanced types.
Conference / content culture

Talks and posts about wild TypeScript tricks perform well. Talks about “use simple types, they age better” do not.
Engineer ego

It feels good to bend the type system to your will. It is less glamorous to say, “We could, but we shouldn’t.”
Lack of boundaries

We never collectively agreed on a red line like: “Beyond this level of complexity, we stop and fall back to simpler types and runtime checks.”

So we kept pushing.

And now we have codebases where the runtime logic is straightforward, but the types around it look like an SAT puzzle.

We confuse ‘possible in TypeScript’ with ‘good idea in a real-world codebase.’ They are not the same category.

The Core Argument: Legibility > Exotic Type Wizardry

The case against high-level type gymnastics is simple:

If your types are more complicated than the logic they protect, you are probably doing it wrong.

Strong types are valuable.

But they are not free.

They cost:

time to read,
time to onboard,
time to refactor,
and time to debug when the abstractions crack at the edges.

This trade-off used to be obviously worth it: basic interfaces, enums, discriminated unions — huge value, small complexity.

Today, for many teams, the curve has flipped:

marginal safety improvements,
at the cost of major complexity increases.

At that point, you are not buying reliability.

You are buying a false sense of control while quietly making your system more brittle.

The job is not to push TypeScript to its limits. The job is to make future changes less dangerous for normal humans.

Simple Rules for Saner Types

If you are feeling called out by your own code right now — good.

The way out is not “stop using TypeScript.” The way out is to use it like an adult instead of like a magician.

A few rules that help:

1. Prefer explicit types over over-inferred magic

It is often better to:

write an explicit interface or type alias,
accept slightly more verbosity,

than to rely on a tower of generics that infers everything but is impossible to understand.

2. Cap the depth of advanced types

Informal rule:

one level of conditional types → okay,
nested conditionals + recursion + intersected mapped types → probably not okay.

If a type spans more than 10–15 lines and requires comments to explain itself, consider breaking it apart or simplifying the expressiveness.

3. Model the domain, not the entire universe

Types should describe:

the shapes you actually use,
the constraints the domain really has.

They do not have to model *every possible* configuration that a library theoretically supports.

90% coverage with 30% of the complexity is often a better trade.

4. Use runtime validation when static types fall apart

If advanced types start fighting you:

add good runtime validation (e.g., Zod, Yup, custom validators),
keep static types modest and understandable,
let the runtime layer enforce the last mile of safety.

5. Measure complexity by “who can safely edit this”

If only the original author can modify a type without fear, it is too complex.

Make it a standard that:

at least two other devs can explain and edit any core type definition,
if not, it must be simplified or documented to death.

A slightly less clever type that everyone understands is worth more than a perfect type that everyone tiptoes around.

Where This Hurts Most: API-heavy and CMS-heavy Apps

The worst offenders for type gymnastics today are often:

Strongly typed CMS and headless platforms

Payload, Contentful, Sanity, custom internal CMSs — all trying to give you perfect type safety for content schemas and queries.
API client generators

Tools that generate types for every endpoint, every param, every response shape.
Form and query builders

Libraries that expose highly generic builder patterns and want types to follow every chain.

These tools genuinely solve real problems.

But without restraint, they create types that are:

amazing for autocomplete demos,
brutal for maintenance and debugging.

As an application team, you are allowed to say:

“We will wrap this with simpler app-level types.”
“We are okay with losing some perfect inference in exchange for code we can reason about.”

Enterprise-grade type safety is useless if it also creates enterprise-grade fear of touching the code.

A Healthier TypeScript Culture Going Forward

We do not need to abandon advanced TypeScript.

We need a new default stance:

Use simple, explicit types by default.
Reach for advanced types when there is a clear, recurring pain they solve.
Stop shipping clever type tricks as proof of competence.

What that looks like in practice:

Code reviews that ask “Is this readable?” before asking “Is this the most generic possible?”
Libraries that publish both “full magic” and “simple mode” APIs.
Teams that accept small runtime checks instead of pushing every edge-case into the type system.

If you are a senior developer, this is on you.

Your juniors and your future self will live inside the choices you make about types today.

You are not paid to impress the TypeScript compiler. You are paid to make change safer for your team.

I fix the Angular apps that generalists break.

I’m Karol Modelski, senior Angular developer and frontend architect rescuing legacy B2B SaaS frontends.

If your Angular app is slowing your team down, start with a 3‑minute teardown of your current setup: https://www.karol-modelski.scale-sail.io/

Stop Treating Angular as a Second-Class Framework for UI Components

Karol Modelski — Thu, 16 Apr 2026 08:00:00 +0000

You’ve been promised “Angular support” more times than you can count.

What you got instead was a React library in an Angular costume.

A thin compatibility layer. A demo that technically works, but feels wrong the second you try to build something serious with it.

Angular support is not the same as Angular respect.

And the more you look at how Angular tooling is actually built, the less patience you have for ecosystems that treat Angular like an afterthought.

The Lie Behind “Angular Support”

You’ve seen it.

A UI library announces Angular support.

You click the docs.

You get excited for about 15 seconds.

Then you realize what “support” really means:

awkward APIs that feel imported from another ecosystem,
missing Angular ergonomics,
strange lifecycle edges,
styling and composition patterns that clearly weren’t designed for Angular first.

Technically, yes, it works.

But if your first reaction is “why does this feel like React with extra steps?” , then it’s not a native Angular experience.

”A wrapper is not a first-class developer experience.”

And Angular developers know the difference immediately.

React Gets Products. Angular Gets Adapters

This is the part nobody wants to say too loudly.

In a lot of modern tooling ecosystems, React gets the real product.

Angular gets the adaptation layer.

React gets:

the first-class API,
the best examples,
the cleanest DX,
the product decisions designed around its mental model.

Angular gets:

“integration”,
“compatibility”,
“support coming soon”,
or a wrapper that exposes just enough to close the sales objection.

That doesn’t mean every React-first library is bad.

It means Angular is too often treated as a market checkbox instead of a platform that deserves design respect.

And once you’ve felt that enough times, you stop reading “Angular support” as a positive signal.

You start reading it as a warning label.

Most multi-framework libraries are really one framework with export options.

The Problem Isn’t Just Pride. It’s Product Quality

This is not framework tribalism for its own sake.

Wrapper-heavy ecosystems create real problems:

worse developer experience,
inconsistent abstractions,
harder debugging,
awkward state integration,
weaker performance characteristics,
APIs that don’t fit Angular’s strengths.

When a library is born in one ecosystem and then “ported” into Angular without fully embracing Angular’s patterns, you pay for it everywhere:

in the template layer,
in reactivity,
in change detection assumptions,
in styling APIs,
in the mental overhead of using something that never really feels native.

That cost compounds fast in real products.

A bad wrapper is not just ugly.

It becomes architecture debt.

The ecosystem quality you tolerate today becomes the architecture debt you inherit tomorrow.

Angular Developers Are Not Asking for Special Treatment

The ask is much simpler:

If you say your library supports Angular, then build for Angular like it matters.

That means:

APIs that feel natural in Angular,
composition patterns that respect Angular architecture,
state handling that fits Angular’s reactive model,
docs written for Angular devs, not translated from another framework,
examples that look production-ready, not “we made this demo work once.”

Angular is not some fringe hobby framework.

It powers serious enterprise apps, internal tools, fintech platforms, compliance systems, and big teams that care about long-term maintainability.

So the expectation is not unreasonable.

If the framework is good enough to power critical systems, it’s good enough to deserve native tools , not compatibility leftovers.

If Angular is good enough for core systems, it’s good enough to deserve first-class tools.

Why Developers Are Spending Months on Angular-First Tools

At some point, complaining stops being interesting.

You either keep using wrappers and live with the friction, or someone builds the thing they wish existed.

That’s why you increasingly see stories of developers who spend months building Angular-first tools — including rich text editors — instead of gluing React-centric libraries into their apps.

Not because the world desperately needed yet another editor.

And not because anyone wanted a vanity side project.

They did it because they were tired of pretending Angular developers should be grateful for second-hand abstractions.

They wanted things that felt native from the inside out:

designed around Angular patterns,
built with Signals in mind,
not fighting Angular templates,
not leaking another framework’s assumptions into every integration point.

If your “Angular integration” feels like React with extra steps, it’s not Angular-native.

The deeper you look at these case studies, the clearer the pattern becomes:

Most “Angular ports” aren’t really ports. They’re translations with compromises.

Because once someone tries to build something properly for Angular, it becomes obvious how many “multi-framework” tools are really just one framework with export options.

Signals Changed the Standard

Angular’s ecosystem has a chance right now to stop copying old patterns and start building better ones.

Signals matter here.

Because an Angular-native future should not be:

old wrapper patterns with new branding,
React mental models translated into Angular syntax,
or generic abstractions that ignore what Angular is actually good at.

It should be:

signal-first APIs,
cleaner state flows,
better template ergonomics,
components designed for Angular’s architecture instead of awkwardly tolerated by it.

This is where Angular devs need to get more ambitious.

Not “Can we get this React thing working in Angular?”

But:

What would the best possible Angular-native version of this tool look like?

That’s a much better question.

And honestly, it’s long overdue.

The Angular Community Needs More Conviction

One of Angular’s biggest ecosystem problems is not technical.

It’s psychological.

Too many Angular developers have been trained to accept less:

fewer native libraries,
slower ecosystem momentum,
weaker mindshare,
and “good enough” wrapper support.

That creates a strange defeatism.

People start talking like Angular is lucky just to be included.

It isn’t.

Angular deserves builders who act like it’s worth building for.

Angular doesn’t need more compatibility. It needs conviction.

That means more developers creating:

Angular-first component systems,
Angular-native editors, tables, charts, and design tools,
signal-based primitives,
and products that don’t apologize for not being React.

Because if Angular developers keep waiting for React ecosystems to save them, they will keep getting what they’ve always gotten:

Adapters.

Wrappers.

Second-class support.

If you keep acting like Angular is second-class, don’t be surprised when the ecosystem treats it that way.

This Isn’t About Beating React

React is not the villain here.

React won the mindshare war for a reason:

huge ecosystem momentum,
lower barrier to experimentation,
enormous commercial gravity around component libraries and UI tooling.

Fine.

But Angular developers keep making the mistake of treating that as proof that Angular should just consume whatever React produces.

That’s not strategy.

That’s dependency.

The real question is not:

How do we get more React libraries into Angular?

The real question is:

What tools should exist because Angular exists?

That’s how you build a healthier ecosystem.

Not by begging for parity through wrappers, but by creating products that are unmistakably native.

Native Angular Tools Will Always Feel Better

A real Angular-native tool gives you things wrappers rarely do:

APIs that match Angular instincts,
predictable integration into Angular architecture,
cleaner mental models,
fewer translation layers,
less framework dissonance.

And when the product itself is designed for Angular from day one, the quality difference shows up everywhere:

in how fast teams onboard,
in how easy it is to debug,
in how natural it feels to extend,
in how much trust there is in the tool long-term.

That trust matters.

Because teams don’t just adopt components.

They adopt maintenance futures.

A wrapper always feels like borrowed infrastructure.

And borrowed infrastructure is the first thing people want to rip out when things go wrong.

The Manifesto

So here’s the position, clearly:

Stop calling wrappers “great Angular support.”
Stop rewarding ecosystems that treat Angular as a checkbox.
Stop acting grateful for tools that were never truly designed for Angular developers.
Stop lowering the bar for what “Angular-native” should mean.

Start building:

better Angular-first libraries,
signal-based primitives,
tooling that respects Angular architecture,
products that feel like they belong in Angular, not merely tolerate it.

If Angular is good enough for the hardest problems, it’s good enough to deserve first-class tools.

If you are building for Angular, build with standards high enough that nobody has to ask whether it was native.

They should feel it instantly.

Angular Deserves Better

This is bigger than one editor, one library, or one complaint.

It’s about whether Angular developers keep accepting second-class tooling in a first-class framework.

You can read plenty of stories of teams who inherited Angular apps full of awkward wrapper libraries and half-baked integrations.

Once those abstractions land in a codebase, they stay there for years.

That’s why this matters.

The shortcuts you accept at the library level become the nightmares you debug at the product level.

The ecosystem quality tolerated today becomes the architecture debt inherited tomorrow.

Angular deserves better than wrappers.

And if the ecosystem is not going to hand Angular better native tools, then Angular developers will have to build them.

That’s not just a technical decision.

It’s a standards decision.

A community decision.

A respect decision.

So yes — stop treating Angular as a second-class framework for UI components.

And start building like it isn’t one.

I fix the Angular apps that generalists break.

I’m Karol Modelski, senior Angular developer and frontend architect rescuing legacy B2B SaaS frontends.

If your Angular app is slowing your team down, start with a 3‑minute teardown of your current setup: https://www.karol-modelski.scale-sail.io/

Your Tech Stack Isn’t Your Ceiling. Your Story Is

Karol Modelski — Thu, 09 Apr 2026 08:00:00 +0000

For most of my career, I treated my tech stack like a progress bar.

More Angular. More RxJS. More Nx. More Supabase. More AI tools.

If I just kept adding skills, the ceiling would move up automatically.

I kept upgrading my stack and my career stayed exactly the same.

I hit a point where I had a loaded stack and a surprisingly flat trajectory.

Freelance matches were thin. Take‑homes still got rejected. My own AI SaaS hit friction that more syntax couldn’t fix.

I didn’t hit a skills ceiling. I hit a positioning ceiling.

The Senior Playbook: Add Frameworks, Hope for the Best

Watch how most senior devs “level up”:

They add another frontend framework (React, Next, Svelte).
They sprinkle in a backend (Node, .NET, Java, Go).
They experiment with a new database, a cloud provider, maybe Kubernetes for good measure.

The CV gets longer.

The LinkedIn headline becomes a tech‑stack salad.

The feeling is: “I’m more employable because I know more tools.”

In reality, what you often get is horizontal growth:

You go from “Angular dev” to “Angular + React + Node dev”.
But you’re still competing in the same generic pool: “senior fullstack developer who can build features.”

If your LinkedIn headline is just a list of tools, you’ve already lost the story game.

Meanwhile, the market is quietly rewarding people who did something else:

They picked a niche (“I fix broken fintech dashboards that lose users on step 3 of onboarding.”).
They productized their value (“Performance and UX audits that lift conversion by 15% in 2 weeks.”).
They learned to tell a story about their work, not just list the tech.

And then AI arrived and quietly pushed the stack race into even stranger territory.

My Case Study: Maxed Out on Angular, Stuck on Story

Here’s my situation, stripped of ego.

I’ve been in Angular for 7+ years.
I’ve done legacy migrations, zoneless modernizations, Signal‑based state, Nx monorepos, performance work.
I use Claude Code and Antigravity heavily to move faster.
I can operate as the “Legacy Rescue” person: the one who drops into a messy Angular codebase and turns chaos into something you can ship.

On paper, that looks great.

In practice:

Most “Angular roles” now want fullstack with .NET or Java on the backend — stacks I don’t want to go into.
Angular‑only freelance opportunities are fewer, and many still treat you like a generic pair of hands.
I started my own solo company: building AI‑driven SaaS and offering automation consulting. Both need web and mobile, and I can’t hide in “Angular only” anymore.
Even with AI support, I hit friction on things like Supabase, auth, RLS, and mobile — not because they’re impossible, but because my brain was still wired around “stack first.”

My instinctive solution?

“Maybe I should add React. Or Next. Or a backend stack. Or something new…”

But when I looked honestly at what was actually blocking me, it wasn’t the lack of one more framework.

It was the fact that I was still thinking like a stack , not like a story.

What “Your Story” Actually Means as a Developer

Let’s clear something up: “your story” is not a fluffy bio paragraph.

In a tech context, your story is the through‑line that answers three questions:

1. Positioning — Who are you for?

— “I rescue legacy Angular apps for B2B SaaS founders who can’t afford downtime.”

— “I build fast MVPs for non‑technical founders in fintech.”

— “I design developer tooling that cuts CI times in half.”

2. Niche — What specific problem do you own?

— “Angular performance & modernization for compliance platforms.”

— “AI‑powered internal tools for ops teams drowning in spreadsheets.”

— “Onboarding flows for SaaS with high trial drop‑off.”

3. Product value — What outcome do you reliably create?

— “We cut your largest Angular page LCP by 40%.”

— “We ship your MVP in 4 weeks so you can sell before you hire.”

— “We reduce your manual ops time by 30% with automations.”

Notice what’s missing:

“I know Angular, React, Node, Next, Prisma, Postgres, Tailwind, Docker, AWS.”

Your tech stack is the implementation detail behind that story.

Clients, hiring managers, and users care far more about the story.

Most seniors don’t have a stack problem. They have a positioning problem disguised as a stack obsession.

AI Changed the Stack Equation (Whether We Like It or Not)

Before AI coding tools, being “the person who knows X” was a real edge.

You knew Angular inside out.
Or you knew React best practices before others.
Or you knew how to hand‑roll Node backends quickly.

Now?

Claude Code can scaffold an unfamiliar stack.
AI can translate patterns between frameworks.
Antigravity can reason about codebases you haven’t even seen before.

This doesn’t make expertise useless.

But it shrinks the value of “I’ve memorized every corner of this framework” as your main differentiator.

AI can help you:

wire up a basic Supabase schema,
draft RLS policies,
hook Next.js to Stripe,
scaffold a mobile client in React Native.

What AI can’t do for you:

choose the right problem to solve,
pick a clear niche with money and urgency,
design a valuable product around that problem,
tell a compelling story about why your solution matters,
build trust with the people who pay you.

AI can fake a stack. It can’t fake a story, a niche, or a value proposition.

If you keep treating “leveling up” as “adding more stack”, you’re racing in a lane that AI is rapidly commoditizing.

AI will happily write yet another CRUD app; it won’t convince anyone they should pay you senior rates.

How I’d Actually Choose a Stack Today (Assuming AI Support)

So how do you decide what to build with, as a senior dev in 2026?

If we assume you’re willing to lean on AI to fill gaps, the stack decision comes after three questions:

1. Who is this for?

— Example: B2B SaaS founders with a broken Angular app.

— Or: ops teams in fintech drowning in manual workflows.

— Or: solo founders who need to validate an AI product in 4 weeks.

2. What painful bottleneck am I solving?

— LCP/TBT too high, users bailing on dashboards.

— Manual processes blocking growth.

— No MVP, no sales conversations, just “ideas”.

3. Where does the value live?

— In a dashboard? A small internal tool? A marketing site? A mobile touchpoint? An automation that runs in the background?

Only after that do I pick a stack, with three constraints:

Can I reason about it? (I don’t need to be an expert, but I must be able to debug it with AI help.)
Can AI accelerate me in it? (Good tooling, good examples.)
Will my buyer care what I used? (Spoiler: usually not, as long as it’s stable and maintainable.)

For example:

For my AI SaaS MVP, a pragmatic choice might be:

— Next.js for the app,

— Supabase for auth and data,

— Stripe for billing,

— plus AI tools to patch my non‑Next gaps.

The buyer doesn’t care that it’s not Angular. They care that it works, loads fast, and makes them money.
For my consulting, the opposite is true:

— I should double‑down on Angular as a stack,

— but package it as Angular audits, detoxes, and modernization sprints, not “hours of Angular.”

Your stack is a cost function and a delivery detail.

Your story is the value proposition.

The Real Ceiling: Over‑Indexing on Stack, Under‑Indexing on Story

Here’s the pattern I see (in myself and other seniors):

We pour energy into:

learning new frameworks,
adding more tools to the CV,
chasing the “hottest” stack on Twitter.

We under‑invest in:

clarifying who we actually serve,
narrowing to a problem we can own,
collecting and telling stories of outcomes, not features,
packaging our skills into offers that are easy to buy.

And then we quietly wonder:

why our applications look like everyone else’s,
why we feel “replaceable” in interviews,
why our freelancing rates stall,
why our own products struggle to gain traction.

Your biggest bottleneck probably isn’t your stack. It’s how forgettable your story is.

The ceiling isn’t that you “only know Angular” or “only know React”.

The ceiling is that your work is indistinguishable from every other “senior dev” who learned the same stack and never turned it into a story.

What “Leveling Up” Looks Like in Practice Now

If I rewired my own senior‑dev leveling plan around this, it would look less like:

“Add React, then Go, then AWS cert 1, then AWS cert 2.”

And more like:

Sharpen positioning

— “I fix the Angular apps that generalists break for B2B SaaS and fintech.”

— or “I build AI‑powered internal tools that cut ops time by 30%.”
Define 1–2 niches

— Angular modernization for compliance platforms.

— AI‑powered automation for data‑heavy teams.
Productize my work

— Fixed‑scope Angular audit.

— 2‑week performance sprint.

— AI automation pilot with one clear success metric.
Use AI to bridge stack gaps on demand

— Need a tiny Next.js marketing site? Let AI bootstrap it and I reason check it.

— Need to wire Supabase RLS safely? Draft with AI, then review as an architect.

— Need a mobile companion? Use AI to scaffold React Native or Flutter and validate quickly.
Tell the story publicly

— Medium articles that walk through legacy rescues, performance wins, and AI‑assisted builds — not just “here’s how to use X API”.

— LinkedIn posts that show before/after metrics and decisions, not just tools.

— Case studies on my site framed as narratives, not portfolios.

The stack is now a servant of the story, not the star of the show.

Your Tech Stack Isn’t Your Ceiling

I’m not against learning new frameworks.

I’m still improving my web fundamentals. I’m still expanding beyond Angular where it makes sense. I still enjoy the craft.

But I no longer believe my next breakthrough will come from adding yet another logo to my profile.

Your tech stack gets you into the room. Your story decides what happens once you’re there.

Your story is:

who you serve,
what bottleneck you remove,
what outcomes you can point to,
how clearly you can explain it.

AI will keep eroding the advantage of “I know this stack slightly better than the next person.”

The advantage it can’t touch is “I know who I’m for, what I solve for them, and I can ship value fast — with whatever stack makes sense.”

Before you learn another framework, try writing a better story about the ones you already know.

So before you commit to the next framework on your roadmap, try this:

Write one paragraph that starts with:

“I help [who] go from [pain] to [result] by [what you actually do].”

If that feels harder than learning a new tool, that’s a sign.

It’s not your stack that’s holding you back.

It’s the story you haven’t written yet.

I fix the Angular apps that generalists break.

Karol Modelski is a senior Angular developer and frontend architect rescuing legacy B2B SaaS frontends.

If your Angular app is slowing your team down, start here: https://www.karol-modelski.scale-sail.io/