If you run more than one coding agent at a time, you probably know the feeling. The Herdr site sums up the problem well. Agents often die when you close the window. You can't tell which agent needs your attention. And handing results from one agent to another means copying and pasting by hand.

I installed Herdr three days ago to fix exactly this. This post covers what it is and the ideas that make it work.

What Herdr is

The project describes itself as "the runtime your coding agents live on". Put more plainly, it's a terminal multiplexer built for coding agents. If you've used tmux, the basic shape will feel familiar. A background server keeps your terminals running, and a client attaches to show them. The difference is that Herdr is mouse-first and agent-aware.

It ships as a single Rust binary, with no Electron. It's free and open source under the Apache 2.0 license. Everything here is based on version 0.9.5 of the terminal app. It's early days, but I've been fascinated by how powerful it is, and I plan to keep testing it. The Herdr site now also promotes a desktop app. This post is about the original terminal version.

Idea one: a persistent server

The first thing Herdr fixes is the most basic one. Your panes live in a background server, not in the window you happen to be looking at. If you detach, close the terminal, or lose your SSH connection, the agents keep working. Run herdr again and you're right back where you left off.

Since version 0.9.4, closing the shell that started Herdr doesn't stop the server either, and sessions now survive a Mac restart. That's exactly the kind of safety net I want when several agents are mid-task.

Idea two: workspaces, tabs and panes

Herdr organizes everything into three layers.

• A workspace is a project-level container, one per repo or per task. With microservices, that maps neatly to one workspace per service.

• A tab is a layout inside a workspace. For example, I might have one tab for agents, one for logs and one for the dev server.

• A pane is a real terminal, split to the right or downward, and it survives the client detaching.

Every one of these gets a short, stable ID, such as w1 for a workspace, w1:t1 for a tab, and w1:p1 for a pane. IDs are never reused after something is closed, which matters a lot once scripts and agents start pointing at them.

You can drive all of this with the mouse: click to focus, drag split borders, right-click for menus. Keybindings are optional. If you prefer tmux habits, there's a prefix key, Control-B by default, followed by a single action. For example, prefix then v splits right, and prefix then c opens a new tab.

There's one more feature that caught my eye, and that's worktrees. The herdr worktree create command makes a git worktree, opens it as its own workspace, and groups it under the parent repo in the sidebar. That gives each agent its own branch and its own folder, so they can work in parallel without trampling each other's files.

Idea three: agents with states

This is the part that makes Herdr more than a nice tmux alternative, and the one that fixed my window-hopping problem. Herdr recognizes the coding agent running in each pane and gives it a state. It does this by finding the agent's process and reading the bottom of the live screen, then matching it against detection rules that update automatically.

The states are simple:

• Idle means the agent is at its prompt, ready for input.

• Working means it's busy.

• Blocked means it's showing an approval, question or permission prompt. This is the one I care about most. Herdr only knows the prompts it's been taught, so an unfamiliar question can still show as idle.

• Done means it finished, but I haven't looked yet. A done agent stays visible in the sidebar until I view it.

• Unknown means an agent is there, but Herdr can't tell what it's doing.

These states roll up per workspace in the sidebar, so one glance tells me which project has an agent waiting on me. Herdr can also send a notification when a background agent finishes or needs input, either inside Herdr, in the terminal, or as a system notification.

Detection covers a long list of agents, including Claude Code, Codex, GitHub Copilot CLI, Cursor Agent, OpenCode, Gemini CLI and more. For many of them there's also an optional integration, which reports the session identity so Herdr can resume the same conversation after a server restart.

The real trick: agents driving agents

Herdr has a command-line interface and a socket API, and they aren't just for me. Any script, or any agent, can use them too. That opens the door to orchestration, where one agent coordinates the others.

Picture asking one agent to handle a bigger job. It splits the work into roles, such as one agent to research, one to build and one to review. It starts each of them, gives each a name, and sends each one its instructions. Then it waits for each one to finish, reads what it wrote, and decides what happens next. Maybe it passes the result along to the next agent, or sends it back with fixes. There's no copy-paste in that loop, and you don't have to sit in the middle of it.

Even more interesting, the agent doesn't just use Herdr. It can rearrange it to fit the task. It can lay out its own workspace and split new panes right beside itself without stealing your focus. It can start exactly the agents it needs in those panes. It can even give each one its own worktree, the feature I mentioned earlier, so they never trip over each other's files. Herdr stops being a workspace only you arrange and becomes one the agent arranges too.

A couple of safeguards keep this from turning chaotic. A prompt won't be typed into an agent that's blocked on a question, so an instruction can't accidentally answer a permission prompt. And a timeout isn't proof that nothing was sent, so the rule is to read the agent before retrying.

To get Claude Code playing along, run herdr --skill and save what it prints as a Claude Code skill. That skill teaches Claude Code to use all of this politely, like never closing a pane it didn't create.

Getting started

On macOS or Linux, you can use the install script from herdr github repo, or Homebrew with brew install herdr.

There are also options for mise, Nix and Windows. Once it's installed:

1. Move into a project folder and run herdr.

2. Start claude, codex or another agent in a pane. Herdr detects it automatically.

3. Optionally run herdr integration install claude so sessions can resume after a restart.

To stay current, run herdr update . There are also eleven built-in themes if you want Herdr to look the part.

Wrapping up

Before Herdr, running several agents meant babysitting IDE windows. Now my agents keep running when I close things, the sidebar tells me who needs me, and the agents can pass work to each other without me in the middle.

If you're already juggling two or three coding agents, give it an afternoon. Start with a single workspace and a couple of panes, then try letting one agent prompt another. That's the moment it clicked for me.

What actually changed

Three settings ship with stricter defaults in v11:

• minimumReleaseAge (default 1440, in minutes — 24 hours): pnpm won't install a dependency version, direct or transitive, until it's been on the registry for at least this long. That's the cooldown — a malicious version published an hour ago can't get pulled into anyone's install before someone notices and yanks it.

• blockExoticSubdeps (default true): only the dependencies listed directly in your root package.json may resolve from a git repo or a tarball URL. Every transitive dependency has to come from a trusted source — your registry, a local path, a workspace link, or a trusted GitHub repo. A dependency three levels deep quietly pointing at someone's GitHub fork no longer flies.

• strictDepBuilds (default true): if any dependency has an unreviewed build or postinstall script, pnpm install now exits with a non-zero code instead of just running it.

Put together: pnpm used to trust the registry and your dependency tree by default. v11 flips that — everything is unreviewed until you say otherwise.

The migration trap: five settings become one

The build-approval change is where most teams will actually get stuck, because it isn't additive — it's a replacement. v11 removes onlyBuiltDependencies, onlyBuiltDependenciesFile, neverBuiltDependencies, ignoredBuiltDependencies, and ignoreDepScripts outright and replaces all five with one setting, allowBuilds — a map of package-name patterns to true/false in pnpm-workspace.yaml:

allowBuilds:
 esbuild: true
 core-js: false

If any of those five old settings were in your config, they're silently ignored now — not an error, just gone — and any package with a postinstall script that isn't explicitly listed in allowBuilds counts as unreviewed. With strictDepBuilds: true as the default, your next clean install just exits non-zero. For a team running esbuild, sharp, native bindings, Playwright, or anything else with a build step, that's most installs.

The fix is one command, run once per repo: pnpm approve-builds. With no arguments it's interactive — it lists every pending package and lets you approve or deny each one. You can also skip the prompt: pnpm approve-builds esbuild fsevents !core-js approves the first two and explicitly denies the third (a ! prefix denies), or pnpm approve-builds --all approves everything pending in one shot if you trust your current tree. Either way, the decision gets written straight into allowBuilds in pnpm-workspace.yaml — commit that file so the rest of the team, and CI, inherit the same approvals instead of everyone hitting the same wall individually.

Where your .npmrc settings actually went

.npmrc isn't gone, but its job shrank: as of v11 it holds registry and auth settings only. Everything else moves to pnpm-workspace.yaml, or to the new global ~/.config/pnpm/config.yaml for machine-level settings. Concretely:

• Per-scope registries (@scope:registry=... lines) become a registries map in pnpm-workspace.yaml.

• Per-project .npmrc overrides become packageConfigs in pnpm-workspace.yaml.

• The node-mirror:<channel> setting becomes nodeDownloadMirrors in pnpm-workspace.yaml.

• Network settings — httpProxy, httpsProxy, noProxy, localAddress, strictSsl, gitShallowHosts — move to the YAML config too, though pnpm still reads them from .npmrc for now to ease the transition.

• Environment variables switch from npm_config_* to pnpm_config_*; the old prefix is no longer read at all.

None of these fail loudly if you miss one — they just stop applying, which is worse than a hard error if you're relying on one for a private registry or an internal mirror. Worth a dedicated pass through your current .npmrc rather than assuming the upgrade carries it forward.

CI considerations: what stalls if you track latest

minimumReleaseAge is the one most likely to bite you first, and only in CI, which makes it extra fun to debug. If your pipeline resolves against a floating version — tracking latest, or a loose ^/~ range — and the version that would satisfy it was published inside the last 24 hours, pnpm won't resolve to it; that's the setting working as designed. Locally this rarely shows up, because you installed a day ago and your lockfile is already pinned. In CI, especially on a fresh runner with no cache, you can hit a brand-new release at exactly the wrong moment.

Two ways to handle it, and the right one depends on why you're floating in the first place: if you're intentionally tracking fresh releases — an internal package your own team ships multiple times a day, say — set minimumReleaseAge: 0 for that package, or workspace-wide if the cooldown doesn't suit your setup. If you're floating by accident because nobody got around to pinning, pin the version instead and let the cooldown do its job everywhere else. Either way, don't discover this failure mode in production CI first — run an install against a clean cache before you flip the upgrade on everyone.

A realistic rollout plan for a three-person team

Nobody on a three-person team has time to be “the pnpm 11 person” full time, so this is built to take an afternoon, not a sprint.

1. Pilot on one repo. Pick the smallest, least business-critical one you've got. Upgrade pnpm, run pnpm approve-builds interactively so you actually see every package being approved, and commit the resulting pnpm-workspace.yaml.

2. Audit .npmrc before touching the others. Now that you know what moved, go through the pilot repo's old .npmrc line by line and confirm every setting has a new home, or confirm it genuinely was registry/auth and belongs where it is.

3. Run a cold-cache CI install. Trigger a pipeline run without a warm cache before merging, so you catch a minimumReleaseAge resolution failure now, not three weeks from now at an inconvenient hour.

4. Roll out repo by repo, not all at once. Copy the now-proven pnpm-workspace.yaml pattern to the next repo rather than re-discovering the same five-settings issue there.

5. Decide your minimumReleaseAge policy once, in writing, not per-repo. Zero-cooldown for internal fast-moving packages, the 24-hour default for everything external — and apply that consistently instead of re-deciding it under pressure every time CI fails.

The new defaults exist for a real reason, but a restrictive default you don't understand yet is just friction with better branding. Thirty minutes with the pilot repo turns pnpm 11 from a surprise into a checklist.

Sources:

• pnpm 11.0 release notes

• pnpm settings: dependency resolution

• pnpm settings: build

• pnpm CLI: approve-builds

Before you can join a session, GTA Online loads its net shop catalog: about 10MB of JSON describing roughly 63,000 purchasable items. t0st found two separate problems in how the game read that file. First, its parser was built on sscanf, and most sscanf implementations call strlen on their input — so reading each value meant measuring a 10MB string all over again. Second, after parsing each item, the game scanned every item stored so far to detect duplicates before inserting it. That check scaled quadratically: double the catalog, and the work roughly quadruples, reaching about 1.98 billion comparisons at 63,000 items. It was also pointless, because every item in the catalog was unique. Years of new items had grown that file, so code that was probably fine at launch had become the dominant cost of joining a session.

The fix itself wasn't exotic. t0st's proof of concept, built entirely client-side with no access to Rockstar's source, cached the string's length so strlen stopped rescanning it, and inserted items directly instead of running the duplicate check. On t0st's machine, loading fell from about six minutes to 1 minute 50 seconds, a cut of roughly 70%. The parser was the bigger culprit: patching it alone brought the load down to 2 minutes 50 seconds, while patching only the duplicate check reached 4 minutes 30 seconds. Rockstar eventually shipped an official update that resolved the problem.

What makes this worth knowing as a backend or full-stack developer isn't the GTA trivia — it's how invisible this class of bug is from the inside. Nobody at Rockstar set out to write an O(n²) parser; it's almost certainly code that was correct and fast when the data was small, and nobody revisited the algorithm as the data grew by orders of magnitude over years of live updates. That's a very normal way for performance bugs to form: not a bad decision at the time, but a reasonable one that stopped being reasonable as scale changed underneath it, with no single commit that "caused" it.

The practical takeaway scales down easily: when something that used to feel instant has quietly gotten slow, profile it before assuming it's infrastructure. A JSON parse, a config reload, a "just loop through and check" validation step — these are exactly the places where a small, forgotten loop ends up owning your latency budget as your own data grows.

Sources: How I cut GTA Online loading times by 70% · Hackers Succeeded in Reducing Load Time in Grand Theft Auto: Online by 70% · Hey Rockstar, GTA Online Has A Bad CPU Bottleneck That Slows Loading But There's A Fix

shopId | priority | name

101 | 1 | Rule A

101 | 2 | Rule B

101 | 3 | Rule C

Two requirements, both non-negotiable: (1) shopId + priority stays unique, and (2) users can reorder rules. Try to satisfy both with the obvious approach and you'll hit a wall fast.

Why the simple update fails

You want to swap Rule A and Rule B — Rule B moves to priority 1, Rule A moves to priority 2. Wrap it in a transaction and it still fails:

BEGIN;

UPDATE rules SET priority = 1 WHERE name = 'Rule B';

-- At this point, two rows have priority = 1

-- DB throws "Unique Constraint Violation"

UPDATE rules SET priority = 2 WHERE name = 'Rule A';

COMMIT;

A regular unique index checks each row the moment it changes — it cannot temporarily bypass the constraint, so the data has to be valid at every single step, not just at the end. The transaction wrapper doesn't help, because the transaction was never the problem; the ordering of statements inside it was.

The other obvious move — dropping the index and validating uniqueness in application code — trades this problem for a worse one. Now nothing stops two rows from actually ending up with the same priority if two requests race, or if someone touches the table directly. You've satisfied "reorder works" by giving up "uniqueness is guaranteed."

The fix: DEFERRABLE constraints

PostgreSQL lets you mark a constraint DEFERRABLE, which lets the uniqueness check wait until COMMIT instead of running as each row changes:

ALTER TABLE public.rules

ADD CONSTRAINT "UQ_ShopId_Priority"

UNIQUE ("ShopId", "Priority")

DEFERRABLE INITIALLY DEFERRED;

With that in place, the exact same swap transaction just works:

BEGIN;

UPDATE rules SET priority = 1 WHERE name = 'Rule B';

-- DB does NOT throw "Unique Constraint Violation" — the constraint is deferred

UPDATE rules SET priority = 2 WHERE name = 'Rule A';

COMMIT;

-- Uniqueness is validated right here, against the final state

Nothing about the guarantee changed. The constraint still gets enforced, and the transaction still fails if the final state has a duplicate — you've only moved when it checks, from "as each row changes" to "once, against the state that actually matters."

IMMEDIATE vs. DEFERRED

A deferrable constraint gives you two modes, and you can flip between them mid-transaction with SET CONSTRAINTS:

• A plain UNIQUE index/constraint (no DEFERRABLE at all) checks each row as it changes, permanently — you cannot change this per-transaction.

• DEFERRABLE INITIALLY IMMEDIATE checks at the end of each statement by default, which is later than a plain constraint, and any transaction can flip it to DEFERRED on the fly with a command.

• DEFERRABLE INITIALLY DEFERRED checks at COMMIT time by default, and any transaction can flip it back to IMMEDIATE the same way.

For a table whose writes are mostly ordinary single-row inserts and updates, INITIALLY IMMEDIATE is the safer default — you opt into deferred checking only for the transactions that need it. INITIALLY DEFERRED makes more sense when swaps and reorders are most of what happens to that table anyway.

Where this beats the usual workarounds

The two workarounds people reach for instead — and where they fall short, especially once an ORM like EF Core is in the picture:

• The temp-value hack — move a row to a dummy value like priority = -1 to free up the slot, then move it again. It works, but it's 3 updates instead of 2, and now your application logic has to know about a hack that has nothing to do with the actual business rule.

• The single-statement shift — shove an entire range with one UPDATE, e.g. SET priority = priority + 1 WHERE priority >= X. On a plain unique constraint this is less clean than it looks: rows are updated one at a time in storage order, so the shift can hit a duplicate partway through and fail. It needs a DEFERRABLE constraint, and even INITIALLY IMMEDIATE is enough, because the check waits for the end of the statement. It also only works for continuous blocks — inserting into the middle of a list. An arbitrary swap between two non-adjacent rows isn't a range shift, and this approach doesn't cover it.

DEFERRABLE isn't a replacement for either workaround in every case — it's specifically better for the case both of them handle badly: an arbitrary multi-row swap that needs to pass through a temporarily invalid state on the way to a valid one.

Key takeaways

• When to use it: complex, multi-statement transactions that need to pass through a temporarily invalid state — reorders, swaps, anything in that shape.

• Performance: deferrable uniqueness checks cost more than plain ones, and PostgreSQL's docs warn they can be significantly slower. Worth weighing on a high-throughput table — this is a tool for specific swap/reorder cases, not a default for every unique constraint.

• Data integrity: unchanged. The constraint still guarantees no duplicates exist once the transaction finishes — you've only changed when it's checked, not whether.

• Compatibility: standard SQL, but support is split — Postgres and Oracle have it; MySQL and SQL Server don't.

• Upserts: a deferrable constraint can't be the target of INSERT ... ON CONFLICT, so PostgreSQL rejects upserts that rely on it.

Thanks to Angelos Constantinides for the discussion that sharpened this one.

Read the presentation deck on LinkedIn

1. The development lifecycle itself is changing shape

The report calls this a "tectonic shift": tactical work — writing, debugging, maintaining code — moves to AI agents, while engineers spend more of their time on architecture and system design. Onboarding timelines reportedly collapse from weeks to hours in some organizations, which changes how teams staff projects dynamically. The concrete example that stood out: Augment Code helped an enterprise customer finish a 4-to-8-month project in two weeks. That's the kind of number that should make you ask "under what conditions," not just take at face value — but it's a useful upper bound for what's now possible.

2. Single agents are turning into coordinated teams

Instead of one agent doing everything in sequence, organizations are running multiple specialized agents in parallel under an orchestrator — each with its own context window and role. The report's example here is Fountain, which used hierarchical multi-agent orchestration to get 50% faster candidate screening, 40% quicker onboarding, and cut fulfillment-center staffing time from over a week to under 72 hours. The skill this demands — breaking a task down so separate agents can work on pieces of it without stepping on each other — is basically a new discipline, closer to distributed-systems design than prompt-writing.

3. Agents are running for hours, not minutes

This is the trend with the number that actually made me stop and re-read it: Rakuten used Claude Code to implement activation vector extraction inside vLLM — a 12.5-million-line codebase — in seven autonomous hours, with 99.9% numerical accuracy. That's not a toy benchmark; that's a real, large, unfamiliar codebase. The broader point is that task horizons are expanding from minutes to days or weeks of autonomous work, which means agents increasingly have to plan, iterate, recover from their own errors, and hold onto project context the whole way through — not just produce one clean diff and stop.

4. Oversight doesn't disappear — it scales differently

Back to that 60%-usage-but-0-to-20%-delegation number: the report is explicit that effective AI collaboration still requires active human judgment, and that agents are increasingly used to review other agents' output for security and architectural consistency — a second AI reading the first AI's homework, with a human still deciding what matters. CRED's case study frames this well: they doubled execution speed across their whole development lifecycle not by removing developers from the loop, but by shifting them toward higher-value review and design work. That distinction — speed from reallocation, not from absence — is the part I think gets lost when people summarize this report as "AI writes the code now."

5 & 7. Coding is leaking out past engineering entirely

Two of the report's trends are really one story: agentic coding is reaching legacy languages (COBOL, Fortran) and domain-specific tooling, and non-engineers — sales, legal, marketing, operations — are building their own automations directly. Zapier's number is the standout: 89% AI adoption across the entire organization, with 800-plus internal AI agents deployed, and design teams reportedly using Claude artifacts to prototype live during customer interviews instead of coming back weeks later with mockups. Legora's case study points the same direction from the other side — they use Claude Code to build their own product, and expose agentic capabilities so lawyers can build sophisticated automations with no engineering background at all. The line between "people who code" and "people who don't" is getting genuinely blurry.

6. The economics change what gets greenlit

TELUS's numbers are the clearest illustration: 13,000+ custom AI solutions built internally, engineering code shipped 30% faster, and over 500,000 hours saved at an average of 40 minutes per AI interaction. The report frames this as three compounding multipliers — agent capability, orchestration quality, and human experience using the tools — stacking into step-function gains rather than incremental ones. One stat worth sitting with: about 27% of AI-assisted work is described as things that simply wouldn't have gotten done otherwise — exploratory work and small quality-of-life improvements that used to lose the prioritization fight. That's a real, if less flashy, source of value.

8. The same tools cut both ways on security

The report doesn't dodge this: agentic tools democratize security review and hardening for defenders, but the same capability lowers the bar for reconnaissance and exploit development on the offensive side. Its stated conclusion is that teams who bake agentic security review into their process from the start end up better positioned — not because the tools favor defense inherently, but because defenders who adopt early get the head start.

What this looks like on a 3-person team

None of the case studies above are a 3-person shop, which is exactly why the report's core tension — 60% usage, 0-20% real delegation — matters more here, not less. There's no second reviewer with spare context to catch a mistake; often it's just me, reviewing my own intern's agent-assisted work, or my own. So in practice: boilerplate, mechanical refactors, and first-draft docs go to an agent without a second thought. Anything touching auth, payments, concurrency, or an architecture decision gets read line by line, no exceptions — and with the intern, that category gets a hand-written first pass before an agent ever touches it, so the reps that build judgment don't get skipped. The test I use before merging anything agent-written: if this breaks at 2am, will I know why within five minutes? If not, that's the review I skipped, and it's cheaper to do now than at 2am.

Sources: 2026 Agentic Coding Trends Report (Anthropic), 8 trends shaping software engineering in 2026 (Tessl).

What actually changed under the hood

The new native compiler (internally called tsgo) keeps the original compiler's structure and logic, just ported to Go instead of JavaScript. Microsoft's own numbers put build-speed gains at 7.7x to 11.9x across their test projects — VS Code's own compile dropped from 125.7 seconds to 10.6 seconds — with memory usage down 6% to 26% depending on the codebase.

Two smaller changes matter more for day-to-day migration work. target: es5 is gone — not deprecated, gone — and now throws a hard error with no fallback. And the types compiler option now defaults to an empty array instead of implicitly pulling in every @types package in your project. If something in your code relies on ambient globals from a types package you never import directly, it'll quietly stop resolving until you list it explicitly, e.g. "types": ["node"].

The real blocker: no programmatic API until 7.1

This is the part that actually decides whether you can upgrade today. Tools like typescript-eslint, @vue/compiler-sfc, @angular/compiler-cli, and svelte-preprocess don't just call the TypeScript compiler — they hook into its internals (ts.createProgram, ts.transform, ts.factory) to parse and rewrite AST nodes. TypeScript 7.0 shipped without that Programmatic Compiler API entirely — it wasn't trimmed down, it just isn't there yet — so any tool built on top of TypeScript's internals, not just "TypeScript the language," is locked out until it comes back. Framework maintainers have responded by pinning strict peer-dependency ranges rather than risk a broken build. Microsoft has said 7.1 is expected to restore a stable version of that API.

A compatibility checklist before you touch tsconfig

• Check whether your team relies on typescript-eslint, Vue SFC compilation, Angular's compiler-cli, or Svelte preprocessing — all currently blocked pending the 7.1 API.

• Grep every tsconfig.json in the repo for target: es5 or lower — it's now a hard build error, not a warning.

• Look for code that depends on ambient @types globals from a package you never import directly — it'll need to be added explicitly to types now.

• Check ts-jest, ts-morph, or anything else with typescript as a peer dependency for a version range that actually covers 7.0.

• Confirm your editor's TypeScript language-service plugin supports 7.0 — some IDE integrations lag a version behind.

Benchmark your own build times before you commit to it

The published numbers are from Microsoft's own test matrix — worth confirming on your actual codebase before treating them as a given. Node 26.9 introduced a node:bench module, but it still sits behind an --experimental-bench flag, so for now a plain timed build is the more reliable measure: record your current build time (time npx tsc --noEmit, or your actual build command), then re-run it after upgrading in a branch — twice each, so a cold cache doesn't skew the comparison.

Recommended rollout path for a small team

1. Pin your current TypeScript version in package.json and leave main alone for now.

2. Test the upgrade in an isolated branch, run the checklist above, and see what actually breaks rather than guessing.

3. If nothing in your toolchain touches the Programmatic Compiler API, the upgrade is likely safe to merge once your own benchmark confirms the win.

4. If you do lean on ESLint through typescript-eslint, Vue, Angular, or Svelte tooling, it's simpler to hold off and revisit once 7.1 ships the API — working around it with an older TypeScript pinned just for those tools isn't worth the complexity for a small team.

This is the exact checklist I'll be running before touching TypeScript in a shared repo — and probably sitting on 6.x a little longer for anything that leans on typescript-eslint.

Sources: Announcing TypeScript 7.0, Why Angular, Vue, and ESLint can't upgrade yet, Node.js 26.9.0 release notes.

Being a volunteer is one of the greatest and most important characteristics in a person. Helping others, and especially animals - that are helpless - is a big accomplishment and takes courage.

During my 3rd year at the university, I had the honor to be part of a group project on creating a website for a shelter called Roberts Dog Sanctuary. The course we were having was Web Development I and the teacher assigned us different real world projects with real clients. We had the good luck to be assigned to a dog shelter.

We met with the director of the shelter, Dagmar, a really nice lady - and most importantly an animal lover - to discuss their needs and requirements for the website.

She told us that the shelter is mostly re-homing dogs abroad, thus their major issue was to find a way to simplify the process of adoption. They wanted to have all the dogs on the website so people could easily see the available dogs. Moreover, when a person would like to request or adopt a dog, they should have been able to fill out a form and submit it through the website.

Having that in mind, along with other minor requirements, our team started working on it. We began with analyzing the requirements and brainstorming the ideas. Thereafter, we proceeded with the design. Unfortunately, during that semester, we only created a prototype of the website to be continued on the next semester.

January 2020. This semester we were going to build a fully functional website based on the prototype we created the previous semester. We were all too excited for this project. As time went by, we put together a really nice website and at the end of the semester we delivered a fully functional website.

Dagmar and the volunteers at the shelter were very happy and grateful for this work, so they wanted us to migrate the website to a new host - their own hosting provider - and make it live.

Here we are now, in the process of migrating to a new host and preparing the website to go live!

We are very happy and grateful to be given such opportunity and we hope all our little friends (dogs) find their forever home!

If you are interested in adopting a dog, feel free to contact the shelter on social media or on the new website which is coming soon!

Facebook: https://www.facebook.com/adoptadogcyprus

Instagram: https://www.instagram.com/robertsdogsanctuary/

Stay tuned, stay positive and stay safe!

This blog is all about connecting with you! I would like to thank you for reading this post and promise you that I am going to share my coding journey with you along with tips and tricks to easier programming!

Keep positive! Keep coding!