The first time I opened a terminal, I stared at it for a solid minute.

No buttons. No menus. No helpful icons.

Just a black screen and a blinking cursor that seemed to be asking, “Well? What are you waiting for?”

If you’ve ever felt intimidated by the command line, you’re not alone. The terminal has an unfair reputation. Movies portray it as a mysterious tool used by elite hackers, while online forums are full of stories about people accidentally deleting important files with a single command.

It’s enough to make any beginner nervous.

The most common fear is simple:

“What if I type the wrong thing and break my computer?”

The good news is that the terminal is far less dangerous than most people think. In reality, it’s not a weapon waiting to be misused—it’s a conversation between you and your operating system.

Like any conversation, once you learn a few basic words, everything starts to make sense.

In this article, we’ll strip away the mystery and focus on a handful of beginner-friendly commands that help you navigate your system confidently. By the end, you’ll understand how to move around, find your way back when you’re lost, and—most importantly—stop being afraid of that blinking cursor.

The Myth of the “Self-Destruct Button”

The Fear

“I’m going to destroy my computer by typing the wrong thing.”

It’s a reasonable concern. The terminal looks powerful because it is powerful.

The Reality

Your operating system has safeguards in place. Most potentially dangerous actions require elevated privileges, often through commands such as sudo, which stands for SuperUser Do.

Without those permissions, your computer actively prevents many system-level changes.

For beginners learning navigation commands, you’re essentially exploring in a safe environment. You’re looking around, not rewiring the house.

Think of the Terminal as Read-Only Exploration

Before changing anything, let’s learn how to look around.

These commands are completely safe because they only display information.

pwd — Where Am I?

Think of pwd as your GPS.

pwd

Output:

/home/brendan/projects

It simply tells you your current location in the filesystem.

No files are modified.
Nothing is deleted.
Zero risk.

ls — What’s Here?

Think of ls as opening your eyes.

ls

Output:

Documents Downloads Pictures projects

It lists the contents of your current directory.

Again, nothing changes. You’re simply observing.

When I was learning the terminal, I probably ran ls hundreds of times because I was constantly checking where I was and what was around me.

That’s completely normal.

Taking Control: Moving Around

Once you know where you are, it’s time to move.

cd — Change Directory

Imagine clicking through several folders in a graphical file manager:

Documents → Projects → Portfolio → Website

In the terminal, you can jump there instantly:

cd Documents/Projects/Portfolio/Website

No clicking required.

The more projects you work on, the more you’ll appreciate how much faster this becomes.

cd .. — The Universal Undo

Made a wrong turn?

Use:

cd ..

This moves you back one directory level.

Think of it as the terminal equivalent of saying:

“Actually, take me back.”

It’s one of the most useful commands you’ll ever learn.

What to Do When You Get Stuck

Every beginner eventually runs into a moment where:

• A command won’t stop running.
• The screen fills with text.
• Something looks confusing.
• Panic starts creeping in.

Fortunately, the terminal comes with built-in escape hatches.

Ctrl + C — Emergency Stop

If a command seems stuck, press:

Ctrl + C

This tells the terminal:

Stop whatever you’re doing and give me my cursor back.

Learning this shortcut instantly made me more confident because I realized I wasn’t trapped if I made a mistake.

clear (or Ctrl + L) — Start Fresh

When your screen becomes cluttered:

clear

Or use:

Ctrl + L

The terminal clears the screen and gives you a clean workspace.

Sometimes the best debugging technique is simply removing the visual chaos and starting again.

Final Thoughts

The terminal isn’t scary because it’s dangerous.

It’s scary because it’s unfamiliar.

Every developer, system administrator, DevOps engineer, and cybersecurity professional started exactly where you are now: staring at a blinking cursor and wondering what to type next.

The secret isn’t knowing hundreds of commands.

It’s knowing a few basic ones well enough to explore confidently.

Start with:

• pwd
• ls
• cd
• cd ..
• clear

And remember your panic button:

• Ctrl + C

Once you master these, that blinking cursor stops looking intimidating and starts looking like an invitation.

Do you remember your first experience with the command line? What surprised you the most?

Here’s a number that will either reassure you or unsettle you depending on where you sit in the developer hierarchy.

Workers with AI skills earned 56% more than colleagues doing the same jobs without those skills in 2026. The year before, that premium was 25%. The year before that, 18%. It’s not flattening. It’s accelerating.

Here’s the other number: senior software developers saw a 10% salary decline year-over-year. Senior. Not junior. Not mid-level. Senior developers with years of experience watched their market rate fall while a subset of their peers with specific AI fluency saw theirs climb at 9.2% annually.

The job didn’t collapse. It forked.

One fork leads toward a market where your value is measured by how much code you produce, and AI has made that kind of value dramatically cheaper. The other fork leads toward a market where your value is measured by whether you can design systems, direct agents, govern output quality, and make architecture decisions that AI can’t make on its own.

The developers choosing the second fork — deliberately, not accidentally — are the ones whose compensation trajectories look anomalous in a flat market. This blog is about how they made that choice and what it actually looks like in practice.

What happened to the job description

The traditional senior developer job description, simplified, looked like this: deep expertise in a specific language or framework, strong ability to write correct and maintainable code, ability to debug complex problems, ability to mentor juniors and review PRs.

The 2026 version of that job description at a well-run engineering organisation looks notably different. The emphasis has shifted from writing to directing, from syntax to architecture, from individual contributor to systems thinker.

Addy Osmani, engineering leader at Google, described the shift as moving from coder to conductor to orchestrator. At the start of 2024, AI-assisted programming resembled a significantly improved autocomplete. By 2026, the transition is to agent systems that operate on codebases over time.

What that means concretely: the most valuable thing a senior engineer can do in 2026 is not write a feature. It’s define the architecture that lets an agent write the feature correctly. It’s create the context files that make agents generate consistent, idiomatic code. It’s build the test infrastructure that catches what agents get wrong. It’s review the agent’s output with the judgment of someone who understands the system deeply enough to spot the subtle errors.

The skills that mattered most in 2021 — fast accurate implementation, deep framework knowledge, encyclopaedic API recall — are the exact skills that AI tools have made cheaper. The skills that matter most in 2026 are the ones AI tools don’t have: judgment, architectural thinking, understanding of tradeoffs, and the ability to know when AI output is wrong even when it looks right.

The two roles senior developers are splitting into

Senior developers in 2026 are effectively splitting into two categories: code validators and architects. If you choose validation — code review — you’ll be in demand but burned out.

That framing is a little stark, but it captures something real. Here’s a fuller picture of what each path looks like.

Path 1: The AI Orchestrator

This is the role that has the strongest compensation trajectory and the most clearly defined skill set.

An AI orchestrator doesn’t primarily write code. They design the system within which agents write code. They author the context files, rules, and architectural boundaries that guide agent behaviour. They define acceptance criteria that agents must satisfy. They review agent output for architectural soundness, not just syntactic correctness. They manage the MCP integrations that give agents access to the right tools. They run parallel background agents on different parts of the codebase and integrate the outputs.

The skills this requires are old and new simultaneously. Old: system design, domain modelling, architectural pattern knowledge, understanding of non-functional requirements (performance, security, scalability). These are the skills that take years to develop and can’t be replaced by prompt engineering. New: context engineering, agentic workflow design, knowing which tasks to delegate and how to brief them, governing AI output quality at scale.

The new standard for senior developers is context orchestration — the ability to guide agentic IDEs that understand the entire repository, documentation, and architectural patterns.

Path 2: The Specialist Who Goes Deeper

Not every developer needs to become an AI orchestrator. The other path with a strong compensation trajectory is going deep in areas where human expertise is still clearly irreplaceable and where AI tools augment rather than replace.

Security engineering is one example. The tools generate insecure code at a documented rate and are worst at the subtle architectural vulnerabilities that only deep security knowledge catches. Security engineers who understand the full threat model, can trace attack surfaces through AI-generated code, and can design systems that are secure by construction are in shorter supply in 2026 than they were in 2024, not longer. The AI made the problem bigger, not the expertise less valuable.

Performance engineering is another. AI generates functionally correct code. It doesn’t generate code that’s been profiled against your actual traffic patterns, optimised for your specific hardware characteristics, or designed with the full operational context in mind. The developer who can take AI-generated output and make it production-ready from a performance standpoint is doing work AI doesn’t do.

Distributed systems architecture is a third. The agent can implement a microservice. It can’t decide whether you should have a microservice, whether the boundaries are right, whether the consistency model is appropriate, or whether the failure modes are acceptable for your specific reliability requirements. Those decisions require human judgment informed by years of building things that broke in unexpected ways.

GenAI Engineer and MLOps Specialist postings are growing at 2–3× the rate of traditional roles year-over-year. Developers who layer AI fluency on top of solid software fundamentals are commanding salary premiums of 15–25% above peers without AI skills.

The salary data, stated plainly

AI Engineers earn 12% more than general Software Engineers in equivalent roles and levels. The premium is higher for specialised LLM developers, who average $209,000. Mid-level AI engineers saw the highest year-over-year gains at 9.2%. Senior software developers without AI specialisation saw a 10% salary decline year-over-year.

Workers with AI skills earn 56% more than same-role colleagues without those skills — a premium that has more than doubled from 25% in 2024. The premium accrues almost entirely to experienced practitioners with genuine production depth. Surface familiarity with AI tools is now table stakes, not a differentiator.

That last sentence matters more than the headline number. The 56% premium doesn’t accrue to developers who have used Copilot for six months. It accrues to developers who have built production AI systems, who understand the failure modes, who have fixed things when they broke, and who can make architectural decisions about where AI belongs in a system and where it doesn’t.

The premium is accessible. It’s not easy.

What “AI fluency” actually means for career development

There’s a version of this conversation that reduces to “learn prompt engineering.” That’s not what the salary data is tracking. Here’s what it’s actually tracking.

System-level thinking about AI integration. Understanding where AI agents belong in a technical architecture — what they should be trusted to do autonomously, what should require human review, what should never be delegated. This requires understanding the failure modes well enough to design around them. Developers who have shipped things that broke because of AI output and understand exactly why are more valuable than developers who have only shipped things that worked.

Context engineering as a discipline. The ability to create the information environment — CLAUDE.md files, rules files, architecture decision records, system prompts — that makes agents perform reliably and consistently. This is not writing prompts. It’s designing the persistent layer of institutional knowledge that makes AI tools behave like they understand your system.

Quality governance at scale. As AI generates more code faster, the bottleneck shifts to quality validation. The ability to review AI output efficiently, catch what’s subtly wrong, and build automated validation that scales — test suites, linters, security scans, architecture fitness functions — is increasingly what distinguishes teams that ship reliably from teams that ship fast and break things.

MCP and tool integration design. Deciding which external tools agents should have access to, what permissions are appropriate, how to scope access safely, and how to design workflows that use agents effectively for real tasks. This is infrastructure thinking applied to AI tooling.

None of these skills are learned by watching tutorials. They’re learned by building things, having them break, understanding why, and building better the second time. The developers who are making the transition well are the ones who have enough production experience that their AI fluency is anchored in real understanding — not just fluency with the tools themselves.

The honest roadmap for developers who want to make this shift

If you’re a developer who has been coding for three-plus years and wants to shift toward the higher-value end of this market, here’s what that actually looks like as a practice.

Build and break a production AI system. Not a toy project. Something with real traffic, real data, and real failure modes. The goal is to experience what happens when an AI component behaves unexpectedly in production — hallucination, context drift, reasoning errors under edge cases — and to understand how to build systems that handle those failures gracefully. This experience is what the premium is actually paying for.

Get deep on context engineering. Spend a week doing nothing but improving your CLAUDE.md and rules files and measuring the output quality difference. Build architecture decision records for your team’s non-obvious conventions. Create a Codebase Orientation document for the project you know best. This practice builds the intuition for what makes AI tools effective at the system level.

Take ownership of your team’s AI governance. If your team is using AI tools without systematic quality governance, offer to build it — the code review standards for AI-generated code, the security review checklist, the test coverage requirements. This work is undervalued, genuinely useful, and directly demonstrates the skills the market is paying for.

Write the architectural documentation that AI tools need. Go through your codebase and document the decisions that AI tools consistently get wrong because they don’t have the context. Why does the payments module use optimistic locking? Why is the notification system pull-based rather than push-based? Why does the user authentication flow have that seemingly redundant step? This documentation is valuable for the AI tools that will read it, valuable for the humans who will onboard to this codebase, and it demonstrates exactly the kind of architectural understanding that commands premium compensation.

Pick one deep specialisation and go all the way in. The developers with the strongest compensation trajectories in 2026 are not generalists with light AI fluency. They’re specialists — security engineers, performance engineers, distributed systems architects — with deep expertise in areas where AI tools create new problems rather than solving them, augmented by AI tool fluency that makes them dramatically more productive. Pick the specialisation that matches your existing depth and go deeper, not sideways.

What the next two years look like

The transition from coder to orchestrator is already taking place and is expected to be mostly complete by 2028. The transition represents a fundamental shift in how software is created — humans will spend less time writing code and more time directing AI agents to do so.

The framing of “will AI take developer jobs” is the wrong question. The right question is: which developer skills will be more valuable in two years and which will be less, and how do you make sure you’re developing the right ones?

The skills that will be less valuable: fast accurate implementation of known patterns, deep memorisation of framework APIs, the ability to write boilerplate quickly. AI has made all of these abundant.

The skills that will be more valuable: system architecture, security judgment, performance engineering, the ability to specify precisely what you want and verify that you got it, understanding of AI failure modes, and the accumulated intuition that comes from building production systems and watching them break.

AI didn’t change what matters. It just made the shortcuts disappear. The developers who thrived by “knowing the frameworks” are now struggling. The ones who understood why systems work the way they do are thriving.

The market has not been subtle about this. The compensation data is clear and the direction of the premium is consistent. The developers who are positioned well are the ones who treated the last two years as an opportunity to go deeper — not the ones who used AI tools as a reason not to.

Originally published on ZyVOP

You buy a NAS for silent, always-on storage. It sits in a corner, humming quietly, doing its thing.

You installed Docker on it for the same reason I did: to save money. Every open-source service you’d otherwise pay a VPS for — your media server, your download automation, your file sync, your home automation bridge — all of it can run on the NAS for free. No monthly VPS bills, no cloud subscriptions, no $5/mo here and $10/mo there that add up to a second rent. Just one box, your box, doing everything.

The problem is that Docker wasn’t designed for spinning disks.

And suddenly the HDDs never stop. Seeking, spinning, clicking, whirring — not occasionally, not every few minutes, but constantly. At 2am you can hear it from the next room. Through a closed door. It drives you insane because you bought this thing specifically so it would not make noise.

I know, because I lived with it for months. Every night, the same clicking. Every morning, the same relief when the TV drowned it out. The NAS was supposed to be invisible, and instead it was the loudest thing in the house.

Here’s what causes it, and how I went from that to 99.9% less noise in one afternoon.

What’s Actually Causing the Noise

Mechanical HDDs make noise when the read/write head moves. The more random the I/O — small reads and writes scattered across the disk — the more seeking, the more noise. Sequential writes to a single file are quiet. Random I/O across thousands of small files is loud.

Docker is pathological for HDDs.

Docker overlay2

Docker’s default storage driver is overlay2. Every container runs on top of layered filesystems — the image layers are stacked, and a thin writable layer sits on top for each running container.

Every file operation inside a container that touches a file from a lower layer triggers a copy-on-write: the entire file gets copied up to the writable layer before the write happens. On an SSD this is fast and silent. On spinning HDDs with mechanical heads, every copy-on-write is a seek, a read, and a write — often scattered across the disk.

And it’s not just copy-on-write. Docker’s overlay2 metadata lives in small files across a deep directory tree. Container startup reads dozens of these. Log rotation writes to them. Health checks touch them. Any container doing anything at all generates constant scattered I/O.

Now multiply that by however many containers you’re running. Every single one is generating random I/O all day, every day. The HDDs never get a break.

Everything Else Piling On

Beyond Docker, a typical homelab NAS has:

• System monitoring tools running on cron (every 5-10 minutes, writing stats to disk)
• systemd journal flushing logs
• The NAS OS itself doing housekeeping

None of these alone would be noticeable. But on top of Docker’s constant churn, the drives never spin down. Not for a second.

Diagnosing Which Process Is the Problem

Before moving anything, confirm what’s actually hitting the disk:

# Real-time I/O per process (needs sysstat)
sudo iotop -o

# Disk utilization over time
iostat -x 2 10

On a typical Docker setup you’ll see the Docker daemon at the top, with periodic spikes from cron jobs.

The Fix: Move Docker Off the HDDs

The HDDs are loud because they’re doing work they shouldn’t be doing. The solution is to give that work to something that doesn’t make noise.

An external SSD connected via USB is cheap, silent, and fast enough for everything Docker needs. USB 3.0 to a SATA SSD delivers 400+ MB/s — far more than any container workload requires.

The goal: the HDDs only handle the NAS OS and your actual data (media, documents, backups). Everything Docker-related moves to the SSD.

What to Migrate

Docker data-root — the overlay2 layers, image cache, container writable layers. This is the biggest source of random I/O and the highest-impact thing to move.

# /etc/docker/daemon.json
{"data-root": "/mnt/external-ssd/@docker"}

Bind-mount volumes — the persistent data your containers read and write (databases, config files). If these live on the HDD, container writes hit the HDD. Move them to the SSD.

For bind mounts, a symlink keeps things transparent — containers keep using the same paths, no reconfiguration needed:

ln -s /mnt/external-ssd/volumes /original/volumes/path

What Stays on the HDDs

• The NAS operating system
• System logs
• Your actual data files (documents, media, backups) — these have sequential I/O patterns that HDDs handle well and don’t cause the constant seeking noise

A Note on Copying Files (UGOS Pro Caveat)

If your NAS runs UGOS Pro (UGREEN’s Debian-based OS), there’s a critical gotcha: rsync will silently corrupt permissions when copying from the NAS filesystem to an external drive. This is caused by proprietary kernel-level xattr hooks in UGOS Pro.

The fix and the full technical explanation are in a separate post: Why rsync Destroys Permissions on UGOS Pro — and the Only Fix That Works

Short version: use tar --xattrs-exclude='ug.*' instead of rsync for any file copy on UGOS Pro.

Mount the SSD Correctly

# /etc/fstab
UUID=<your-uuid> /mnt/external-ssd ext4 defaults,noatime,nofail 0 2

Two flags matter:

• noatime — disables access time updates on every file read. Eliminates a whole class of unnecessary writes.
• nofail — if the SSD disconnects and the NAS reboots, it boots normally instead of hanging at the fstab error.

The Result: Silence

After the migration, the difference is night and day. Before, the HDDs were seeking constantly — a low but relentless clicking that never stopped, day or night. It was the kind of noise you don’t notice during the day but drives you crazy at 3am when the house is silent.

Now? Nothing. The HDDs spin up occasionally — a system log flush, a cron job writing stats — but the constant background noise is gone. The drives spend most of their time parked, doing what they were designed to do: sit there quietly and hold your data.

I’d estimate 99.9% reduction in audible HDD activity. The clicking that used to drive me insane? Completely gone. The NAS is back to being the quiet box in the corner it was always supposed to be.

You don’t realize how much that noise was bothering you until it stops. Trust me.

If your NAS runs UGOS Pro, read the companion post before attempting the migration — the rsync issue will cost you time if you hit it blind: Why rsync Destroys Permissions on UGOS Pro

The moment a plugin needs account data, a simple API call turns into an authentication problem. The bad shortcut is familiar: ask the user to create a personal access token (PAT), make them paste it into settings, and hope it never leaks.

For a JetBrains IDE plugin, use this flow instead: the user clicks the Login button, the browser opens, the provider handles sign-in, the IDE receives a callback, and the plugin stores the token.

At a high level, the plugin will:

1. Open the provider’s authorization page in the browser.
2. Receive the OAuth2 callback inside the IDE.
3. Validate the returned state.
4. Exchange the authorization code with PKCE.
5. Store the access token in PasswordSafe.

This post uses GitHub as the OAuth2 provider, but the same shape works elsewhere. Scopes, URLs, token responses, and refresh rules will change.

Sample code: https://github.com/JetBrains/intellij-sdk-docs/tree/main/code_samples/oauth2

The Mental Model

OAuth2 is easier to reason about as hotel key cards.
At check-in, you do not get a master key. You get a card for your room, maybe the elevator or gym. When your stay ends, the card stops working.

That is the useful bit: allowed access, but limited and temporary. An OAuth2 access token works the same way. The user signs in with the provider, and the plugin gets a token for the API access the user approved. The plugin never needs the user’s password.

That approach is better than asking people to paste a long-lived secret into settings. Users stay in the browser login flow they already trust, while the provider keeps control of scopes, expiration, and revocation.

So the goal is simple: get the plugin a limited token without making the user paste one manually. The catch is that a desktop plugin cannot protect a traditional client secret.

Why PKCE Is Part of the Story

In a web app, the server can keep a client secret on the backend. A desktop plugin cannot do that. Anything bundled into the plugin can be inspected.

That is where PKCE comes in. PKCE stands for Proof Key for Code Exchange, and it ties the returned authorization code to the login request that created it.

Before opening the browser, the plugin creates a random code_verifier and sends GitHub a derived code_challenge. Later, when GitHub redirects back with a temporary code, the plugin sends the original verifier to the token endpoint.

GitHub compares the verifier with the earlier challenge. If they do not match, no token. That means the returned code is not enough on its own, which is exactly what we want for a desktop plugin.

The Flow

Here is the full flow:

1. The user clicks Login with GitHub.
2. The plugin creates state, code_verifier, and code_challenge.
3. The plugin opens GitHub’s authorization URL in the browser.
4. GitHub redirects back to the IDE with state and a temporary code.
5. The plugin validates state.
6. The plugin exchanges the code and verifier for an access token.
7. The plugin stores the token in PasswordSafe and calls the GitHub API.

Where the Flow Lives in Code

The sample code lives in code_samples/oauth2. The flow above is split across four small pieces:

• plugin.xml registers the settings UI and the local callback handler.
• AuthConfigurable gives the user the login and logout buttons.
• AuthRestService handles the request that GitHub sends back to the IDE’s built-in HTTP server.
• AuthService creates the OAuth2 request, exchanges the code, stores the token, and calls the API.

That split is the main thing to notice. OAuth2 feels messy when everything is described as one big mechanism. In code, it is much easier to follow when each class owns one part of the trip.

Register the UI and Callback

The plugin descriptor registers two things:

• the settings page
• the local HTTP callback handler

<extensions defaultExtensionNs="com.intellij">
  <applicationConfigurable
      instance="org.intellij.sdk.oauth2.AuthConfigurable"
      id="org.intellij.sdk.oauth2.AuthConfigurable"
      displayName="My Plugin Auth"/>

  <httpRequestHandler implementation="org.intellij.sdk.oauth2.AuthRestService"/>
</extensions>

applicationConfigurable adds the settings page. httpRequestHandler registers a handler with the IDE’s built-in HTTP server, so a request to /api/myplugin can be routed to AuthRestService. That gives GitHub a local redirect target after browser authorization.

Keep the Settings UI Boring

AuthConfigurable is the settings UI. In the sample, it extends BoundConfigurable, uses the Kotlin UI DSL, and its job is small:

• if disconnected, show Login with GitHub
• if connected, show the username and Logout

The panel observes AuthService.state, and the view is a small state switch:

private fun createView(state: AuthState) = panel {
  when (state) {
    is AuthState.Connected -> row("Username") {
      label(state.username ?: "Unknown")
      button("Logout") { authService.logout() }
    }

    is AuthState.Disconnected -> row {
      button("Login with GitHub") { authService.login() }
    }
  }
}

Receive the Browser Redirect

After approval, GitHub redirects back to the IDE’s built-in HTTP server. The callback is handled with the IntelliJ Platform RestService:

http://localhost:<built-in-server-port>/api/myplugin

AuthRestService reads state and code, finds the pending login request, completes it, and returns a small HTML response:

val parameters = urlDecoder.parameters()
val state = parameters["state"]?.firstOrNull()
    ?: return "No authorization state found"
val code = parameters["code"]?.firstOrNull()
    ?: return "No authorization code found"
val callback = service<AuthService>().callbacks.remove(state)
    ?: return "No active OAuth request found"

callback.complete(code)
sendResponse(
  request,
  context,
  response("text/html", Unpooled.wrappedBuffer(HTML_RESPONSE.toByteArray()))
)
return null

After that, AuthService continues the flow by exchanging the code for a token.

Run the Flow

AuthService creates the login request, waits for the callback, and exchanges the returned code:

private suspend fun requestToken(): String {
  val state = UUID.randomUUID().toString()
  val codeVerifier = UUID.randomUUID().toString().padStart(43, '0')
  val callback = CompletableDeferred<String>().also { callbacks[state] = it }

  try {
    BrowserUtil.browse(authorizationUrl(state, codeVerifier))
    return exchangeCodeForToken(callback.await(), codeVerifier)
  } finally {
    callbacks.remove(state)?.cancel()
  }
}

CompletableDeferred is the bridge between the HTTP callback and the coroutine waiting in requestToken(). requestToken() waits on callback.await(), and AuthRestService completes that same object when GitHub redirects back with the code.

The padStart(43, '0') is there because GitHub expects the PKCE verifier to meet the minimum verifier length. Some providers are less strict and may accept a UUID as-is, but GitHub needs the verifier to be at least 43 characters long.

The authorization URL carries both safety checks: state and the PKCE challenge.

private fun authorizationUrl(state: String, codeVerifier: String) = url(
  AUTHORIZATION_URL,
  "client_id" to CLIENT_ID,
  "scope" to SCOPES,
  "state" to state,
  "redirect_uri" to redirectUri,
  "code_challenge" to codeChallenge(codeVerifier),
  "code_challenge_method" to "S256",
)

The challenge is derived from the code verifier:

private fun codeChallenge(codeVerifier: String) =
  DigestUtil.sha256().digest(codeVerifier.toByteArray())
    .let { Base64.getUrlEncoder().withoutPadding().encodeToString(it) }

The actual token exchange is a POST to GitHub’s token endpoint:

private suspend fun exchangeCodeForToken(code: String, codeVerifier: String) =
  withContext(Dispatchers.IO) {
    parseAccessToken(post(tokenUrl(code, codeVerifier), null).readString())
  }

The token request sends back the temporary code and the original verifier:

private fun tokenUrl(code: String, codeVerifier: String) = url(
  ACCESS_TOKEN_URL,
  "client_id" to CLIENT_ID,
  "client_secret" to CLIENT_SECRET,
  "code" to code,
  "redirect_uri" to redirectUri,
  "code_verifier" to codeVerifier,
)

The sample includes a GitHub client secret because GitHub’s OAuth app flow expects one. For a desktop plugin, do not treat that value as secret. PKCE is the useful check here: the returned code is useless without the original verifier.

Store the Token in PasswordSafe

Once the provider returns an access token, store it in PasswordSafe. Regular persistent settings are fine for preferences, but not for access tokens.

The sample uses one credential key:

private val credentials =
  CredentialAttributes(generateServiceName("MyPluginAuth", "OAuthToken"))

On startup, the service restores an existing token if one was saved earlier:

init {
  coroutineScope.launch {
    val token = PasswordSafe.instance.getPassword(credentials) ?: return@launch
    _state.value = AuthState.Connected(fetchUserProfile(token))
  }
}

Storing and clearing go through the same helper:

private fun storeToken(token: String?) =
  PasswordSafe.instance.setPassword(credentials, token)

For a real plugin, use a stable service name. If you support multiple accounts, store one credential per provider account.

Platform sources: PasswordSafe, CredentialStore, and CredentialAttributes.

Calling the API

After login, the rest of the plugin should not care how OAuth2 worked. The sample uses the external org.kohsuke:github-api library and passes the token into GitHubBuilder to fetch the current GitHub username:

private suspend fun fetchUserProfile(token: String): String? =
  withContext(Dispatchers.IO) {
    runCatching { GitHubBuilder().withOAuthToken(token).build().myself.login }
      .onFailure { thisLogger().warn("Failed to fetch user profile", it) }
      .getOrNull()
  }

Keep that boundary in larger plugins too. API code should not know how browser login works.

Wrapping Up

OAuth2 in a plugin is mostly about putting the responsibilities in the right place.

Let the provider handle sign-in. Let the browser handle the user-facing login. Let the IDE receive the callback. Let AuthService deal with the token. And once the token is stored in PasswordSafe, the rest of your plugin can stop caring how the user authenticated.

If you are building something similar, or if you hit an edge case with a provider, bring it to the JetBrains Platform forum.
Good luck!

In the crowded landscape of API development tools, Bruno has emerged as a refreshing, developer-centric alternative to traditional clients like Postman or Insomnia. If you’re tired of bloated interfaces, cloud-only dependencies, and subscription paywalls, Bruno is designed specifically for you.

What is Bruno?

At its core, Bruno is an open-source, offline-first API client. Unlike many competitors that store your collection data in proprietary clouds or require accounts just to test endpoints, Bruno operates entirely on your local machine.

It stores API collections as a folder of standard text files (.bru files) directly in your project’s file system. This design means your API documentation and test collections live alongside your code, not in a siloed ecosystem.

Why Choose Bruno?

• Offline-first privacy: Runs locally, giving you full control with no forced sync or accounts.
• Git-friendly collaboration: Track changes, review pull requests, and view diffs with Git.
• Minimalist performance: Fast, clean interface without heavy browser overhead.
• Open format freedom: Human-readable .bru files make migration and parsing simple.

Step-by-Step: Push Your Bruno Collection to Codeberg

Because Bruno stores collections as files, versioning them with Git and hosting on Codeberg is straightforward.

Step 1: Create and Locate Your Collection

1. Open Bruno → Create Collection.
2. Choose a name and folder location.
3. To find an existing collection, right-click → Reveal in Finder (macOS) or Open in File Manager (Linux/Windows).

Step 2: Configure .gitignore

Before initializing Git, exclude sensitive data.

cd /path/to/your/bruno-collection
touch .gitignore

Add:

# Ignore Bruno local environment overrides and secrets
environments/*.bru

# Ignore local preferences and cache
.bruno/

Step 3: Initialize Git and Commit Locally

git init
git add .
git commit -m "feat: initial bruno collection setup"

Step 4: Create an Empty Repository on Codeberg

1. Log into Codeberg.
2. Click + → New Repository.
3. Name it (match your collection ideally).
4. Leave “Initialize Repository” unchecked.
5. Click Create Repository.

Step 5: Link and Push to Codeberg

git remote add origin https://codeberg.org/your-username/your-repo-name.git
git branch -M main
git push -u origin main

Best Practices for Bruno & Git

• Keep secrets out: Never push .bru files with production credentials.
• Commit frequently: Update API docs alongside development.
• Use pull requests: Handle reviews and merges with Git workflows.

I recently deployed my fully decentralized content pipeline to kheai.com (you can check out the source code at github.com/kafechew/nostr-seo). After rigorously testing the architecture, I wanted to document exactly how this system works. We are not just building a blog; we are engineering an evergreen, censorship-resistant Web3-to-Web2 bridge.

In this tutorial, you will build an automated pipeline that fetches your long-form articles from decentralized Nostr clients (like Yakihonne or Primal), converts them into a blazing-fast static website using Astro, and hosts it for free on Vercel.

Zero prior Astro experience is required. If you follow these steps, you will go from an empty folder to a live, SEO-optimized prototype.

The Architecture Vision

Before writing code, you must understand the data flow. We are shifting from a “push” model (saving files to a server) to a “pull” model (compiling decentralized data at build time).

graph TD
    A[Author on Yakihonne/Primal] -->|Publishes Kind 30023| B(Nostr Relays)
    C[GitHub Actions Cron] -->|Triggers Build every 6h| D(Vercel Edge Network)
    D -->|Fetches Data| B
    D -->|Compiles HTML/CSS| E[Your Live Website]
    E --> F[Human Readers]
    E --> G[AI Agents via llm.txt]

The Tech Stack

Phase 0: The Digital Workbench

You need a few standard tools installed before we begin.

1. Download and install the LTS (Long Term Support) version of Node.js from nodejs.org.
2. Install Git from git-scm.com.
3. Download Visual Studio Code, the industry-standard code editor.
4. Create free accounts on GitHub and Vercel.
5. Convert your Nostr npub to a Hexadecimal key using a tool like damus.io/key. Keep this Hex key safe; our code needs it to identify you on the network.

Phase 1: Local Setup & Installation

Open your terminal. We will use the AstroPaper template as our foundation.

Run the following command to download the template into a new folder named nostr-seo:

npm create astro@latest -- --template satnaing/astro-paper nostr-seo

Navigate into your new project:

cd nostr-seo

Now, we must install our communication tools (NDK for Nostr) and our processing engines (Unified for Markdown/Math). Run this command exactly as written:

npm install @nostr-dev-kit/ndk ws nostr-tools remark-math rehype-katex rehype-stringify remark-rehype remark-parse unified --legacy-peer-deps

Note: The --legacy-peer-deps flag prevents npm from crashing if the Astro template’s default formatting tools have strict version conflicts with our new parser.

The MacOS/Linux WebAssembly Patch

If you are on an older OS, the build engine (esbuild) might fail. Open your package.json file and append these properties to force Node.js to bypass your core OS framework and use WebAssembly instead:

{
  "devDependencies": {
    "esbuild-wasm": "0.28.0"
  },
  "overrides": {
    "esbuild": "npm:esbuild-wasm@0.28.0"
  }
}

Open the project in your editor by typing code . in your terminal.

Phase 2: Core Engineering & Data Pipelines

Because we are fetching posts from Nostr relays rather than local .md files, we must create a custom processing pipeline to handle rich text, math equations, and metadata.

Step 1: The Markdown Processor

Create a new file at src/utils/parseMarkdown.ts. This utility converts raw Nostr strings into safe, styled HTML.

import { unified } from "unified";
import remarkParse from "remark-parse";
import remarkMath from "remark-math";
import remarkRehype from "remark-rehype";
import rehypeKatex from "rehype-katex";
import rehypeStringify from "rehype-stringify";

export async function parseNostrMarkdown(content: string) {
  const result = await unified()
    .use(remarkParse)
    .use(remarkMath)
    .use(remarkRehype)
    .use(rehypeKatex)
    .use(rehypeStringify)
    .process(content);

  return result.toString();
}

Step 2: The Event Formatter

Create a new file at src/utils/formatNostrEvent.ts. This extracts SEO descriptions and generates proper naddr links for cross-platform Web3 sharing.

import { nip19 } from "nostr-tools";

export function formatNostrEvent(event: any) {
  const findTag = (key: string) => event.tags.find((t: any) => t[0] === key)?.[1];

  const summary = findTag("summary");
  const fallbackDesc = event.content
    .replace(/![.*?](.*?)/g, "") 
    .replace(/[(.*?)](.*?)/g, "$1") 
    .replace(/(?:__|[*#`[]()-+!=])/g, "")
    .substring(0, 160)
    .trim() + "...";

  const dTag = findTag("d") || "";
  let naddr = "";
  try {
    naddr = nip19.naddrEncode({
      kind: 30023,
      pubkey: event.pubkey,
      identifier: dTag,
    });
  } catch (e) {
    console.error("Naddr error", e);
  }

  return {
    id: naddr || event.id,
    title: findTag("title") || "Untitled",
    description: summary || fallbackDesc,
    pubDatetime: new Date(event.created_at * 1000),
    modDatetime: null,
    author: findTag("author") || "Nostr User",
    tags: event.tags.filter((t: any) => t[0] === "t").map((t: any) => t[1]),
    ogImage: findTag("image"),
    content: event.content,
    naddr: naddr
  };
}

Phase 3: Building the Interface

We will hijack AstroPaper’s default routing to dynamically pull your Kind 30023 events at build time.

Step 1: The Homepage (index.astro)

Navigate to src/pages/index.astro. Delete everything and paste the code below. Replace the Hex string with your own public key.

---
import Layout from "@/layouts/Layout.astro";
import Header from "@/components/Header.astro";
import Footer from "@/components/Footer.astro";
import NDK, { type NDKEvent } from "@nostr-dev-kit/ndk";
import 'ws'; 

const ndk = new NDK({ 
  explicitRelayUrls: [
    "wss://relay.damus.io", 
    "wss://nos.lol",
    "wss://relay.primal.net"
  ] 
});

try {
  await ndk.connect(3000); 
} catch (err) {
  console.error("Nostr Connection failed:", err);
}

// REMEMBER TO INSERT YOUR HEX KEY BELOW
const filter = { 
  kinds: [30023], 
  authors: ["YOUR_HEX_PUBLIC_KEY_HERE"]
};

let events: Set<NDKEvent> = new Set();

try {
  const fetchPromise = ndk.fetchEvents(filter, { closeOnEose: true });
  const timeoutPromise = new Promise<Set<NDKEvent>>((resolve) => {
    setTimeout(() => resolve(new Set()), 4000);
  });

  events = await Promise.race([fetchPromise, timeoutPromise]);
} catch (err) {
  console.error("Fetch error:", err);
}

const posts = Array.from(events)
  .filter((e): e is NDKEvent & { created_at: number } => e.created_at !== undefined)
  .sort((a, b) => b.created_at - a.created_at)
  .map(e => {
    const cleanContent = e.content.replace(/[#*`_~[]()-]/g, "").replace(/s+/g, " ").trim();
    return {
      id: e.id,
      title: e.tags.find((t: string[]) => t[0] === 'title')?.[1] || "Untitled Post",
      summary: e.tags.find((t: string[]) => t[0] === 'summary')?.[1] || (cleanContent.substring(0, 120) + "..."),
      date: new Date(e.created_at * 1000).toLocaleDateString('en-US', {
        year: 'numeric', month: 'long', day: 'numeric'
      })
    };
  });
---

<Layout title="My Decentralized Mind-Dump">
  <Header />
  <main id="main-content" class="app-layout">
    <section id="hero" class="border-border border-b pt-8 pb-6">
      <h1 class="my-4 inline-block text-4xl font-bold sm:my-8 sm:text-5xl">My Nostr Mind-Dump</h1>
      <p>Pulled dynamically from the Nostr protocol at build time. Write on Web3, read everywhere.</p>
    </section>

    <section id="recent-posts" class="pt-12 pb-6">
      <h2 class="text-2xl font-semibold tracking-wide mb-6">Recent Notes</h2>
      <ul>
        {posts.map(post => (
          <li class="my-6">
            <a href={`/nostr/${post.id}`} class="inline-block text-xl font-bold text-skin-accent decoration-dashed underline-offset-4 hover:underline">
              {post.title}
            </a>
            <div class="text-sm opacity-80 mt-1">{post.date}</div>
            <p class="mt-2 line-clamp-3">{post.summary}</p>
          </li>
        ))}
      </ul>
    </section>
  </main>
  <Footer />
</Layout>

Step 2: The Article Reader Route

Create a new folder named nostr inside src/pages/. Inside that folder, create [id].astro. This generates dynamic paths for every article.

---
import Layout from "@/layouts/Layout.astro";
import Header from "@/components/Header.astro";
import Footer from "@/components/Footer.astro";
import NDK, { type NDKEvent } from "@nostr-dev-kit/ndk";
import 'ws';
import { parseNostrMarkdown } from "@/utils/parseMarkdown";
import { formatNostrEvent } from "@/utils/formatNostrEvent";

export async function getStaticPaths() {
  const ndk = new NDK({ explicitRelayUrls: ["wss://relay.damus.io", "wss://nos.lol"] });
  await ndk.connect(3000);

  let events: Set<NDKEvent> = new Set();

  // REMEMBER TO INSERT YOUR HEX KEY BELOW
  const filter = { kinds: [30023], authors: ["YOUR_HEX_PUBLIC_KEY_HERE"] };
  const fetchPromise = ndk.fetchEvents(filter, { closeOnEose: true });
  const timeoutPromise = new Promise<Set<NDKEvent>>((resolve) => setTimeout(() => resolve(new Set()), 4000));

  events = await Promise.race([fetchPromise, timeoutPromise]);

  return Array.from(events)
    .filter((e): e is NDKEvent & { created_at: number } => e.created_at !== undefined)
    .map(e => ({
      params: { id: e.id },
      props: { event: e }
    }));
}

interface Props { event: NDKEvent; }
const { event } = Astro.props;
const post = formatNostrEvent(event);
const htmlContent = await parseNostrMarkdown(post.content);
---

<Layout title={post.title}>
  <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/katex@0.16.9/dist/katex.min.css" crossorigin="anonymous" />
  <Header />

  <main id="main-content" class="mx-auto w-full max-w-3xl px-4 pb-12 mt-8">
    <button class="focus-outline mb-6 flex hover:opacity-75" onclick="history.back()">
      <span>← Go back</span>
    </button>
    <h1 class="text-3xl font-bold text-skin-accent">{post.title}</h1>

    {post.naddr && (
      <div class="mt-6 flex flex-wrap items-center gap-3 text-sm bg-skin-card/10 p-4 rounded-lg border border-skin-line/50">
        <span class="font-bold">⚡ Nostr:</span>
        <a href={`nostr:${post.naddr}`} class="text-skin-accent hover:underline">Open in App</a>
        <a href={`https://yakihonne.com/article/${post.naddr}`} target="_blank" class="hover:text-skin-accent opacity-80">Yakihonne</a>
      </div>
    )}

    <article class="prose max-w-none prose-img:border-0 mt-8" set:html={htmlContent} />
  </main>
  <Footer />
</Layout>

<script>
  const renderMermaid = async () => {
    const codeBlocks = document.querySelectorAll("pre code.language-mermaid");
    if (codeBlocks.length === 0) return;
    const { default: mermaid } = await import("https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.esm.min.mjs");
    mermaid.initialize({ startOnLoad: false, theme: "dark" });

    for (const element of codeBlocks) {
      const id = `mermaid-${Math.random().toString(36).substr(2, 9)}`;
      const { svg } = await mermaid.render(id, element.textContent || "");
      const wrapper = document.createElement('div');
      wrapper.className = 'mermaid-container my-8 flex justify-center overflow-x-auto';
      wrapper.innerHTML = svg;
      element.parentElement?.replaceWith(wrapper);
    }
  };
  renderMermaid();
  document.addEventListener("astro:after-swap", renderMermaid);
</script>

Step 3: Global Styling and Contrast Fixes

Add these definitions to src/styles/global.css to fix dark mode contrast, ensure math blocks scroll gracefully on mobile, and apply proper borders to user-uploaded images.

/* Improve contrast for Dark Mode */
html[data-theme="dark"] .prose {
  --tw-prose-body: theme("colors.slate.200");
  --tw-prose-headings: theme("colors.white");
  --tw-prose-bold: theme("colors.white");
}

/* KaTeX Math Styling */
.katex-display {
  @apply my-8 overflow-x-auto py-4 px-2 rounded-lg;
  background-color: rgba(255, 255, 255, 0.03);
}

.katex {
  white-space: nowrap;
}

/* Nostr Image Attachments */
article img {
  @apply rounded-xl border shadow-md mx-auto my-8;
  border-color: var(--color-line); 
}

Start your local server by running npm run dev and opening http://localhost:4321. Your site should now dynamically render your Nostr notes.

Phase 4: AI-Native SEO (llm.txt)

As AI agents like Perplexity and SearchGPT replace traditional search engines, we must provide a semantic layer.

Create a file named llm.txt inside your public/ folder. Write a direct, markdown-formatted summary of your site’s core philosophy and architecture. When an AI scrapes yourwebsite.com/llm.txt, it immediately contextualizes your niche with zero token waste.

Phase 5: Deployment & The Zero-Maintenance Pipeline

It is time to put your site on the public internet and automate the build process.

1. Push your code to a new public GitHub repository.
2. Log into Vercel, click Add New Project, import your repository, and click Deploy. Vercel will grant you a live URL.

The Automation Webhook

Right now, your site is static. If you publish a new article on Nostr, your site won’t update until Vercel builds again.

1. In your Vercel Dashboard, navigate to Settings -> Git -> Deploy Hooks.
2. Create a hook named Nostr-Sync on the main branch and copy the generated URL.
3. In your GitHub repository, go to the Actions tab and create a new workflow named nostr-sync.yml.
4. Paste the following configuration, replacing the URL with your unique Vercel hook:

name: Nostr Auto-Sync

on:
  schedule:
    - cron: '0 */6 * * *'
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger Vercel Build
        run: curl -X POST "https://api.vercel.com/v1/integrations/deploy/YOUR_UNIQUE_VERCEL_HOOK_URL"

Commit the changes.

You have successfully engineered an evergreen architecture. You write natively on Nostr, retaining absolute ownership of your cryptographic keys. Every 6 hours, GitHub Actions silently signals Vercel. Vercel scrapes the relays, compiles your latest thoughts into high-speed HTML, and serves it globally. Write once, syndicate everywhere.

Most TypeScript projects already run ESLint with @typescript-eslint. That covers a lot: explicit any, floating promises, non-null assertions, and more. If your linting setup is solid, you’re catching the obvious issues in the editor before code review.

ESLint rules can’t produce cross-file findings. Each rule runs within a single file’s scope, which means ESLint can’t tell you that an export is unused everywhere in the codebase, that an any-typed value from one file is causing unsafe assumptions five files away, or that two components implement the same logic independently. That’s the gap Qodana fills.

Here are five TypeScript issues worth addressing, organized by what ESLint handles and where it runs out of scope.

Implicit any spreading through your codebase

ESLint’s no-explicit-any catches places where you write any. It doesn’t track what happens when any enters your codebase from external sources, such as from response.json(), a third-party library without types, or an untyped import. Once an externally-typed any value enters your code, it propagates silently through property accesses and function calls. ESLint’s no-unsafe-* rules can catch this, but only if you’re using @typescript-eslint/recommended-type-checked, which requires type-aware linting and is significantly less common than the standard recommended config.

async function getUser(id: string) {
  const res = await fetch(`/api/users/${id}`);
  const data = await res.json(); // type: any

  return data.profile.name; // no error — crashes if profile is undefined
}

response.json() returns any in the standard lib. Everything downstream is untyped. The compiler accepts any property name and any method call. The bug surfaces at runtime. Qodana tracks how any flows through the program across files. When an any-typed value reaches a code path where a specific shape is assumed, it flags the discrepancy, even if that’s several function calls away from where any entered the codebase.

Adding UserResponse doesn’t fix this. It just moves the lie closer to the crash. Type the boundary instead:

interface UserResponse {
  profile: { name: string };
}

const data: UserResponse = await res.json();

If the API response shape changes, the type error surfaces at compile time.

Non-null assertions used as shortcuts

ESLint’s no-non-null-assertion flags every ! operator uniformly. That works, but many teams disable the rule or add broad exceptions because legitimate uses, like after a runtime check, get flagged alongside the dangerous ones. The signal gets noisy, the rule gets turned off, and the problem disappears from view.

function renderUser(user: User | null) {
  return `Hello, ${user!.name}`; // crashes at runtime if user is null
}

const button = document.querySelector(".submit-btn");
button!.addEventListener("click", handleSubmit); // crashes if element doesn't exist

Both examples compile without errors. Both crash under predictable conditions. The ! is often added to silence a type error without fixing the underlying issue.

The correct approach is to handle the null case:

function renderUser(user: User | null) {
  if (!user) return "Guest";
  return `Hello, ${user.name}`;
}

const button = document.querySelector(".submit-btn");
if (button) {
  button.addEventListener("click", handleSubmit);
}

Qodana surfaces non-null assertions as a separate category in the report. Not every ! is wrong, but seeing them gathered in one place makes it easier to distinguish the legitimate uses from the shortcuts, without having to choose between a noisy rule and no rule at all.

Floating promises

ESLint’s @typescript-eslint/no-floating-promises is effective, but it’s a type-aware rule. It requires TypeScript type checking to be enabled in your ESLint config via parserOptions.project. In projects where that’s not configured, or configured only for part of the codebase, the rule silently doesn’t run on uncovered files.

async function onSubmit(data: FormData) {
  saveToDatabase(data); // Promise<void>, not awaited
  router.push("/success"); // runs before save completes
}

TypeScript accepts this without complaint. Calling an async function without await is considered valid syntax, and the return value is discarded. However, this behavior is incorrect: The user sees the success page before the save completes, and any database error is silently swallowed.

async function onSubmit(data: FormData) {
  await saveToDatabase(data);
  router.push("/success");
}

Qodana’s analysis is type-aware by default across the whole project, without requiring ESLint’s TypeScript integration to be separately configured. Floating promises get flagged consistently regardless of how the project’s ESLint setup is structured.

Unused exports

noUnusedLocals in tsconfig catches unused variables within a file. Exported symbols are excluded by design. From the compiler’s perspective, something outside the current file might import them. ESLint’s eslint-plugin-import provides an import/no-unused-modules rule that can detect this, but it requires scanning the entire dependency graph on every lint run and carries significant performance overhead on large codebases. For most projects, it’s not practical to keep it enabled.

// utils/format.ts
export function formatCurrency(n: number): string { ... }
export function formatPercent(n: number): string { ... } // removed feature, still here
export function formatBytes(n: number): string { ... }    // never imported anywhere

All three pass without a warning. But formatPercent and formatBytes are dead code. They add maintenance surface, slow down refactors, and mislead developers who assume exported symbols are in use.

Detecting this requires whole-project analysis. Qodana builds a reference graph across the entire codebase and tracks every import and re-export. Symbols that appear only as sources, never as import targets, get flagged. Neither tsc nor ESLint can do this.

Duplicated logic across files

ESLint doesn’t have native duplication detection. Standalone tools like jscpd exist for this, but they’re not part of your linting pipeline. That means separate setup, separate maintenance, and another thing to remember. The result: logic that gets copied between components or utility files accumulates without anyone flagging it.

// components/UserCard.tsx
function formatUserName(user: User): string {
  if (!user.firstName && !user.lastName) return "Anonymous";
  return [user.firstName, user.lastName].filter(Boolean).join(" ");
}
// components/UserBadge.tsx
function getDisplayName(user: User): string {
  if (!user.firstName && !user.lastName) return "Anonymous";
  return [user.firstName, user.lastName].filter(Boolean).join(" ");
}

This isn’t a style issue. It means bug fixes need to be applied in multiple places, and when they aren’t, behavior diverges silently between the two copies.

Qodana detects duplicated code across files as part of the same analysis pass that surfaces type issues and unused exports. When it appears in the report alongside everything else, it’s harder to deprioritize than a separate tool nobody remembers to run.

Setting up Qodana for your TypeScript project

All five issues above are visible in Qodana’s default profile for JavaScript and TypeScript projects. Here is a minimal qodana.yaml to get you started:

  version: "1.0"
  linter: jetbrains/qodana-js:2026.1                                                                                                                                                                                                             
  bootstrap: npm ci                                                                                                                                                                                                                              
  profile:                                                                                                                                                                                                                                       
    name: qodana.recommended                                                                                                                                                                                                                     
  failThreshold: 0                                                                                                                                                                                                                               
  exclude:        
    - name: All                                                                                                                                                                                                                                  
      paths:
        - dist                                                                                                                                                                                                                                   
        - node_modules

If the first run surfaces hundreds of existing issues, don’t let that block CI adoption. Qodana’s baseline feature captures the current state of the project in a qodana.sarif.json file. Commit it, and from that point on, CI only fails on newly introduced problems. The existing backlog stays visible in the report, but it doesn’t block every PR while you work through it.

Ready to fix common TypeScript issues with Qodana?

Try Qodana and let us know what you think.

Try Qodana Ultimate Plus

We’d like to extend a special thank-you to Qodana developer Lev Liadov for his contribution to this guide.

Trained from scratch and designed for practical deployment, Mellum2 is built for routing, Q&A, sub-agents, and private AI use in software engineering systems.

Today, we’re open-sourcing Mellum2, a 12B model engineered to solve the hardest parts of production AI: latency, throughput, and cost. Built from scratch and released under the Apache 2.0 license, Mellum2 offers a high-performance, cost-efficient alternative for your infrastructure.

Mellum began with code completion; now we’ve evolved it to handle both natural language and code. It is now a versatile tool ready to power routing, summarization, and intermediate reasoning steps across your modern AI workflows.

Whether you want to experiment, fine-tune, or deploy at scale, Mellum2 is ready to run in your own systems.

Try Mellum

Architecture and performance

Mellum2 is engineered to solve the bottlenecks of production-scale systems through its architecture and focused, efficiency-driven design.

• Mixture-of-Experts (MoE) design: The model features 12B total parameters, but because it uses a MoE design, only 2.5B parameters are active per token. This reduces compute costs while enabling high-throughput, low-latency inference for real-time workloads.
• Specialized focus: Unlike many modern models, Mellum2 is not multimodal. It is trained specifically on natural language and code data. This specialization ensures the model excels in software engineering environments while remaining lean and fast.

In our technical report, we detail our model’s performance across code generation, science, math, and reasoning benchmarks. Mellum2 is competitive with other similar-sized models while cutting inference time to less than half – a definitive advantage for production-grade deployments.

Key use cases for Mellum2

• Route and orchestrate AI workloads: Use Mellum2 to analyze incoming prompts and help select the right model or tool for each task.
• Build low-latency RAG pipelines: Retrieve relevant context, use Mellum2 to summarize it, and generate responses instantly.
• Power fast sub-agents in complex workflows: Break down agent pipelines into steps like context gathering, planning, and validation. Use Mellum2 for fast, specialized tasks instead of relying on a single large model.
• Enable private, local AI deployment: Run Mellum2 locally or self-host it to keep code and data fully under your control.

The “focal model” philosophy: Why focused models scale better

As AI systems become more complex, performance bottlenecks shift from raw capability to latency, throughput, and cost at scale. Not every task requires the largest model. Many steps in modern AI systems are repetitive, latency-sensitive, and high-frequency. These steps benefit from a fast and reliable model that can be efficiently routed, hosted, and controlled.

At JetBrains, we believe the future belongs to coordinated systems, not single models. Frontier models will continue to push the limits, but practical AI products also require focal models: fast, specialized components that handle high-frequency tasks efficiently.

That’s the role we see for Mellum2 in the next generation of AI software tooling.

Get started with Mellum2

If you’re building AI systems for software engineering – whether inside an IDE, in a RAG pipeline, as part of an agent workflow, or fully on your own infrastructure – we’d love for you to try Mellum2.

Open source is how better tools get made.

Try Mellum