baseballyama's Blog

rsvelte: Rebuilding the Svelte Toolchain in Rust for the AI Era

baseballyama — Tue, 21 Jul 2026 00:00:00 GMT

At Flyle, running multiple AI agents in parallel has become a normal part of development. In this workflow, agents run type checking and linting after each implementation step, making static checks far more frequent than in primarily human-driven development. When checks run in parallel, they compete for CPU and memory, increasing the latency of each run. An agent cannot start its next fix until the check finishes, so the time a static check takes sets a lower bound on the duration of each agent loop iteration.

In Svelte projects, these static checks are especially slow. To solve this, I am building rsvelte, a project to rebuild the Svelte toolchain in Rust. This article explains why this matters now and what rsvelte does.

tl;dr

AI agents run static checks on every loop iteration, so check time sets a lower bound on iteration time, and CPU/memory usage limits how many agents can run in parallel
Rust and other native toolchains are delivering order-of-magnitude speedups in parts of the static-analysis stack, but the Svelte-specific parts of .svelte processing (parsing, transformation, linting, formatting) still rely on JavaScript implementations
rsvelte is a set of Rust implementations that aims to be a drop-in replacement for the Svelte toolchain. It does not introduce any language-level extensions. It is early stage, and maturity varies by package
On Flyle's production frontend, with 8,795 files in the official check scope, replacing the official svelte-check path with rsvelte-check cut type checking from 51.4s to 30.6s (1.7x, about 56% less CPU, while keeping the JavaScript implementation of TypeScript 5.9.3). Switching the check engine to tsgo brought it to 9.0s (5.7x combined)
With an identical set of Svelte-specific rules, rsvelte-lint is about 20x faster, and all 382 diagnostics match
With eight simultaneous checks, the type-checking gap narrows because the TypeScript phase common to both setups dominates. Shorter individual runs should still reduce overlap in normal use, though this remains to be verified with real agent traces

1. Why check speed matters now

1.1 AI takes on implementation, and quality assurance shifts toward harnesses

As AI agents take on more implementation work, the way we ensure quality changes. Static checks mattered in human-centered development too. But as agents take on more of the implementation work, automated harnesses that verify their output take on a larger share of quality assurance.

I think of these harnesses in several layers: design harnesses that establish and constrain the assumptions agents work from through documentation and types, development harnesses that verify output after each implementation step, and test harnesses that verify behavior. Each is worth its own article, but this one focuses on the core of the development harness: the static analysis stack (formatter, type checking, linter, unused-code detection).

1.2 The execution model of static checks changed

Static checks themselves are nothing new. What changed is how they run.

Static checks mattered before AI too. But it was rare for one developer to launch full checks many times in a short period, or to run the same checks in parallel across multiple working trees. In agent-driven development, both are normal.

Agents work differently from humans. Some agents, like Codex CLI, do not use a Language Server at all. Even when an agent can use one, like Claude Code, parallel instances do not necessarily share a Language Server. If each instance starts its own, the analysis work and memory usage multiply with the number of instances. Also, LSP diagnostics and settings do not always match CI, so in many setups you still need a CLI check identical to CI as the final quality gate. An agent runs checks many times in a single task, and running multiple agents in parallel multiplies the number of concurrent checks. In short, static checks used to run at low frequency and low parallelism. Now they run at high frequency and high parallelism.

To be precise, this is not a problem unique to AI. CI and pre-commit hooks have run full CLI checks for a long time, and slow full checks are a well-known problem. What changed is the frequency and the parallelism. Static-analysis-heavy workflows had already been growing more common for years; parallel AI development pushed the trend to an extreme. That is why this article talks about AI, but the argument below applies to any workload that runs many full CLI checks.

1.3 Slowness costs you in two ways

Slow checks cost you in two connected ways: latency and resource usage.

The first is latency. In a loop that waits for check results before deciding the next fix, check time is the critical path. If a check takes 5 minutes, one iteration takes at least 5 minutes. In my experience, it is not unusual for a full check suite to take several minutes. Even on Flyle's production frontend, measured later in this article, type checking alone takes about 51 seconds (3.3). At that rate, running the check five times in one task adds more than four minutes of type-checking latency.

The second is resources. The current Svelte check stack uses a lot of CPU and memory across its whole process tree, including the TypeScript engine and the transformation step. In the measurements below (3.3), the current JS setup used a peak of 4.2GB of memory and about 105 CPU-seconds for one type check of Flyle's production frontend. Running several checks in parallel can exhaust the CPU and memory of a developer machine. So check resource usage becomes one of the main limits on how many agents you can run at once.

1.4 Why "just use CI" and "just buy a bigger machine" are not enough

Moving checks to CI only delays the feedback. Agents use check results to decide their next fix, so fast feedback inside the loop matters. If implementation continues without checks, new work piles up on top of wrong assumptions, and fixing errors found in bulk later costs more. To guide the next implementation step, the check needs to run inside the loop.

A bigger machine does help. But if each check process uses the same amount of resources, the required CPU and memory grow as parallelism increases. Making the tools more efficient increases the number of agents the same hardware can support.

2. Rust-based toolchains and where Svelte stands

2.1 Static-analysis tools are moving to native implementations

Static-analysis tools are increasingly being rewritten as native-code implementations in Rust, Go, and similar languages.

oxlint, from the oxc project, runs linting 50-100x faster than ESLint (as claimed by the project)
tsgo, a Go port of the TypeScript compiler, claims about 10x faster type checking than tsc (A 10x Faster TypeScript)
Biome applies the same native-toolchain approach to formatting and linting

This speedup is not just "write it in Rust and it gets fast." It comes from the entire design: parallel-first architecture, avoiding unnecessary repeated parsing, memory-efficient data structures, and the performance characteristics of the implementation language.

The important point is that when speed changes this much, behavior changes too. Checks that take 10 minutes overlap across parallel agents and contend for CPU and memory. Shorter checks reduce the window in which concurrent runs can overlap, making resource contention less likely. Better latency can also relieve the resource problem by reducing overlap.

2.2 But the Svelte-specific parts are still JavaScript-based

Svelte-specific processing has not fully caught this wave.

Linting: oxlint has an alpha-stage feature that extracts and checks the script part of .svelte files, but it does not yet provide a foundation for checking Svelte-specific semantics across templates and styles. Svelte-specific rules still depend on the JavaScript-based eslint-plugin-svelte + ESLint
Formatting: oxfmt's Svelte support delegates the Svelte structure to the JavaScript-based prettier-plugin-svelte and hands only embedded JS/TS to oxc_formatter (embedded CSS goes through Prettier's built-in CSS formatter). The .svelte structure and embedded CSS are therefore still parsed and formatted through the Prettier-based path
Type checking: svelte-check converts .svelte files to TypeScript with svelte2tsx and passes them to a check engine. The engine can now be sped up with --tsgo, but the transformation and orchestration remain JavaScript-based

In other words, even the official tools can now speed up the TypeScript part with tsgo, but the Svelte-specific work (Svelte parsing, svelte2tsx transformation, template linting, formatting) still relies on JavaScript implementations. This is not unique to Svelte. Frameworks with their own template languages, such as Vue, face the same problem.

3. rsvelte

rsvelte is a project to close this gap.

3.1 Goal: a drop-in replacement for the Svelte toolchain

rsvelte's long-term goal is to be a drop-in replacement for the existing Svelte toolchain: config files and commands stay the same, and only the implementation changes to Rust. Its design principle is to preserve Svelte's language semantics and compiler behavior rather than adding its own extensions (it does have tool-level extras such as CLI flags and caching).

The reason is to make switching and rollback cost as close to zero as possible in the end. Alternative tools with unique features create dependencies on those features as soon as you adopt them, making it progressively harder to return to the original toolchain. If compatibility is preserved, you can adopt, measure, and roll back safely if something goes wrong. This resembles one part of oxlint's strategy: earning trust by faithfully porting existing ESLint rules. This compatibility is also a prerequisite for eventually proposing maintenance under the Svelte organization, discussed later.

Compatibility is backed by verification, not by declaration. The compiler passes 100% of the 3,500+ in-scope fixtures of the official Svelte v5.56.4 test suite (the Svelte 4 to 5 migrator and a few individual fixtures are out of scope). On top of that, code from about 30 real-world repositories (about 12,000 compilation units) is continuously compiled with both the official compiler and rsvelte, and the outputs are compared. The known structural differences currently stand at 8 for client output and 0 for server output (both as of commit 76ac14b3; the README and dashboard in the repository may show different numbers depending on when they were updated). CI treats the known-difference list as a ratchet, failing if the number of differences increases, and each difference has its cause documented.

That said, how close each package is to drop-in status varies a lot. Passing 100% of fixtures does not mean full public-API compatibility. Constraints remain around options that accept functions, such as cssHash, and the status of each package is in the table in 3.2. Strictly speaking, the current state is not "a finished drop-in replacement" but "a set of compatible implementations moving toward drop-in status through continuous verification."

3.2 Components

rsvelte ships each tool of the static analysis stack as a separate package. Because maturity varies a lot, the table lists both what each package is and where it stands.

Area	Package	What it is	Current status
Compiler	`@rsvelte/compiler`	Rust port of the Svelte 5 compiler	100% of in-scope fixtures pass. Known structural output differences on real code: client 8 / server 0
Build	`@rsvelte/vite-plugin-svelte`	Fork of the official vite-plugin-svelte (same API)	Experimental
Type check (transform)	`@rsvelte/svelte2tsx`	Rust port of svelte2tsx	0 known output differences. The API is async (for WASM initialization), unlike upstream
Type check (CLI)	`@rsvelte/svelte-check`	Port of svelte-check; the check engine can be tsc or tsgo	Early stage. Some CLI flags differ. Not yet recommended as a CI gate without running the official version alongside
Formatting	`@rsvelte/fmt`	Port of prettier-plugin-svelte; works with oxfmt	40 known output differences on real code. Configured via .oxfmtrc (does not read Prettier config)
Lint	`@rsvelte/lint`	Ports 80 rules from eslint-plugin-svelte	Currently a complement to ESLint, not a replacement
Editor	`@rsvelte/language-server` / `rsvelte-vscode`	Language Server and VS Code extension (separate packages)	Formatting and linting only. No type checking, completion, or go-to-definition

Building all these tools together is a consequence, not a goal. The formatter, type checker, and linter all depend on a Svelte parser. But using the JavaScript Svelte compiler from native tools requires crossing a JS runtime or a process boundary, and it cannot plug directly into oxc's AST and semantic pipeline. Sharing one Rust parser (built on oxc) across all tools is the precondition for the oxc integration discussed later.

Type checking needs one more note. The official svelte-check already has a --tsgo option, so both tools can use the same TS engine. rsvelte's difference is the Rust implementation of the svelte2tsx transformation and the orchestration. The benchmarks below therefore include comparisons where the TypeScript implementation is held constant, to isolate the Svelte-side difference as much as possible.

3.3 Benchmarks

I ran the following benchmarks on my own machine for this article. Before reading the numbers, keep two kinds of measurement separate: engine throughput (the transformation and formatting work itself, on files already loaded in memory) and end-to-end (from CLI start to process exit, which is what a user experiences). Engine-level speedups do not translate directly into the same end-to-end speedups.

Main conditions: Apple M4 Pro (12 cores) / 48GB, Node.js 24.13.1, rsvelte commit 76ac14b3 (built from source), Svelte v5.56.4, svelte-check 4.7.3, typescript 5.9.3, tsgo 7.0.0-dev.20260707.2, eslint 10.7.0, eslint-plugin-svelte 3.21.0. All comparisons were run on the same machine and the same corpus, and the reported values are medians across multiple runs. The measurement scripts and raw data are in the rsvelte repository under scripts/bench/ (the latest engine-level results and charts are on the benchmark page).

Measurement details

How to Approach Abstraction and Consolidation

baseballyama — Wed, 11 Feb 2026 00:00:00 GMT

If you have ever been involved in software design, you will not disagree that "data design" is one of the important elements of design.
Note that "data design" in this article is not limited to database table design. I use it in a sense that also covers how you organize business concepts and where you draw boundaries (domain modeling).

What I most want to convey in this article is simple.

Consolidation is not a coding technique; it is a data-design decision (i.e., which concepts you treat as the same, and where you separate them).
And abstraction is inherently hard and takes time. That is exactly why we should have options other than "hurry up and merge everything into one."

tl;dr

Consolidation is not a coding technique; it is a data-design decision (which concepts you treat as the same)
Consolidating based only on "surface-level duplication" in the code tends to break down under future changes
Abstraction is inherently hard, and the right answer can change as premises change
Abstraction is the act of determining what is invariant and what is variable
When in doubt, tolerate duplication (Avoid Hasty Abstraction / Three Strikes Rule)
When in doubt, stop and ask again: "are these really the same concept?"

1. Do not be fooled by the "look" of the code

The most important trap, and the easiest one to fall into, is focusing on "code as written text" itself.

Code is nothing more than the final output of writing down, in the language of software, the "concepts" that were organized through domain analysis and data design. So no matter how similar two pieces of code look, that alone does not make them candidates for consolidation.

For example, picture a shark and a dolphin. Both adopt the survival strategy of "moving fast underwater," so if you write that behavior as code, you will end up with logic that looks very similar at first glance. But if you consolidate them as "the same thing," the design is likely to break down quickly, because their semantics differ fundamentally.

A shark is a fish; a dolphin is a mammal. If you implement a "breathing" operation, for example, a shark needs gill-breathing logic, while a dolphin requires entirely different logic: lung breathing at the surface. If you had forced them together, the center of the consolidation (the base class or shared function) would fill up with if branches to split the breathing methods, and it would break easily with every change.

The point I want to emphasize here is this.

The state of "the code is duplicated" is not necessarily a design flaw; sometimes it is
merely a signal that "the concept to be consolidated has not matured enough yet."

In other words, if you are captured by "how the current code looks," you lose the ability to think in terms of the "origin of the concept" and the "reasons for change" behind it. When you take on abstraction and consolidation, you should focus on the structured "meaning" behind the phenomenon that is the code.

2. Data design decides "what to consolidate and where to separate"

At the beginning of this article, I wrote that "data design" is the work of restructuring real-world concepts into a form the system can handle. This is generally called data modeling.

Data modeling is the work of organizing which entities exist and what attributes each of them has, and then defining the relationships between entities. Put differently, it is also the work of deciding whether to treat similar things as the same (consolidate them) or to separate them as distinct things.

Even when you are dealing with the same "shark" and "dolphin," the reasonable design changes depending on the system you are building. Let us think about this with two examples.

A: A biological simulation system for a research institute

(I have never worked on one, but) in a biological simulation system, doing data design based on biological classification would likely be one strong option. In that case, the data model might look like this.

classDiagram
    class Animal {
        +name: string
    }
    class Fish {
        +breathing: string = "gills"
    }
    class Mammal {
        +breathing: string = "lungs"
    }
    class Shark {
        +locomotion: string = "swim"
    }
    class Dolphin {
        +locomotion: string = "swim"
    }
    Animal <|-- Fish
    Animal <|-- Mammal
    Fish <|-- Shark
    Mammal <|-- Dolphin

B: An underwater creature racing game

On the other hand, for an underwater creature racing game, being able to handle "how fast it swims" might be enough. In that case, the data model would look like this.

classDiagram
    class AquaticAnimal {
        +name: string
        +speed: int
        +stamina: int
    }
    class Shark {
        +name: string = "Shark"
        +speed: int = 80
        +stamina: int = 70
    }
    class Dolphin {
        +name: string = "Dolphin"
        +speed: int = 75
        +stamina: int = 85
    }
    AquaticAnimal <|-- Shark
    AquaticAnimal <|-- Dolphin

As you can see, even when you are dealing with the same shark and dolphin, the result of data design changes depending on what kind of system you are building. And what you consolidate changes along with it.

In A, it is likely reasonable to factor out the shared parts along the lines of biological classification. In B, consolidating at the level of "underwater creature" is the natural choice.

3. Assume that abstraction is hard (and can break)

Abstraction is not the kind of thing where you can always arrive at the right answer easily. If you widen your view a little, even the concepts we take for granted took a long time to be established.

For example, the act of "counting" must have existed since ancient times, but generalizing and systematizing the concept of "number" took a long time. It is also said that counterintuitive concepts such as negative numbers took time before they were widely accepted. (Reference: Timeline of mathematics)

The lesson to draw from this is as follows.

Abstraction is inherently hard
It can take time before "what can truly be consolidated" becomes visible
Duplication in the code arising in the meantime is, to some extent, natural

And in software, there is a factor that makes it even harder: premises change.

3.1 Changing premises break abstractions

For example, suppose there is a system that manages the selling price of products. If you design it on the premise that the tax rate is uniform, it might take the following shape.

classDiagram
    class Product {
        +name: string
        +priceExcludingTax: decimal
        +sellingPrice(): decimal
    }

At this point, you would be tempted to implement sellingPrice() as shared logic, something like "price before tax × 1.10."

But if the premise later changes to "the tax rate differs by product type," as with the introduction of a reduced tax rate, that simple shared implementation breaks down.

classDiagram
    class Product {
        +name: string
        +priceExcludingTax: decimal
        +taxCategory: TaxCategory
        +sellingPrice(): decimal
    }

    class TaxCategory {
        +taxRate: decimal
    }

What matters here is not baking the tax rate into the class, as in "food is 1.08, appliances are 1.10," but rather treating the tax rate as a "rule that can change" and giving it its own place in the design (it may also vary by period or by country).

Going one step further, the following perspective is the core of abstraction.

The "number" that is the tax rate is variable
The "rule" of calculating the tax amount (the fact that a calculation exists) is close to invariant

Abstraction is the work of determining the boundary between this "invariant" and "variable."
And future changes in premises can shift that boundary. I believe this is the biggest reason abstraction is hard.

4. How to take on abstraction

That said, if we give up on abstraction, the code will keep growing full of duplication, and it will eventually become hard to maintain. So we need to take on abstraction within a realistic scope.

There are two approaches I consider effective.

Clarify the product concept, and consider a wide range of possible future developments
Research similar cases thoroughly

4.1 Clarify the product concept, and consider a wide range of possible future developments

When considering abstraction, the most important thing is the product concept.

For example, if the concept is "a system that manages the tax amount of all products and streamlines company-wide operations," then

generality that holds up across all products handled company-wide
resilience to change on the premise of operation over years (tax law revisions, and so on)

are likely to be required.

You cannot fully predict how tax law will be revised, but you can research "what patterns are possible." You need to look at the tax systems of various countries and regions and the trends of past revisions, grasp the range of changes that could occur, and then decide "how much of that range to include in the design as requirements."

On the other hand, if the concept is "a system that, for now, manages the tax amount of the products my own team handles," then

a design that limits the scope of target products
pragmatic simplifications leaning on near-term operational premises (e.g., a fixed 10% tax rate)

can also be reasonable.

In this way, data design changes greatly depending on the product concept, and as a result the direction of abstraction changes too.

4.2 Research similar cases thoroughly

Abstraction is hard. That is exactly why it is realistic to assume that the probability of deriving a near-best answer from your own experience and knowledge alone is not high.

So I recommend researching what data designs similar software adopted, and why.

The design philosophy of existing products
Published design documents and case studies
Model designs and discussions in OSS (issues, PRs, and so on)

From this kind of information, you can take in "the process by which multiple people wrestled with the problem" and still make the final call in a way that fits your own context. As a result, I believe your chances of reaching a sound answer are higher than thinking alone.

5. What to do when you find code that looks consolidatable

From an implementer's standpoint, I understand the urge to consolidate when you find code that is clearly the same. In such cases, I recommend considering the following.

Ask yourself, from a data-design perspective, whether these two pieces of code are essentially the same concept (a review, an outside perspective, a discussion, or bouncing ideas off an LLM all work)
Even if you do consolidate for now, design it so that you can dismantle it quickly if it turns out to be wrong (keep the callers' dependencies thin, create boundaries, and so on)

In addition, having "rules of thumb" for the decision makes it easier to avoid getting stuck.

When in doubt, tolerate duplication (Avoid Hasty Abstraction)
Only once the same thing appears in three places should you start considering consolidation (Three Strikes Rule)

The value of consolidation is not that it lets you write less.
You need to think about how far the coupling cost created by consolidation will make itself felt in the future.

The claim of this article is not "never consolidate when you find shared code."
It is simply "judge consolidation by conceptual identity, not by how the code looks."

I also believe that a major cause of technical debt lies in flaws in data design (domain design). That is exactly why, if you have the habit of going back to data design when you find "shared code," you may be able to slow the accumulation of debt.

Summary

Consolidation is not a coding technique; it is a data-design decision (treating concepts as the same, and separating them)
Abstraction is hard, and it can "break" in the future when premises change
The core of abstraction lies in determining the boundary between "invariant" and "variable"
Tolerating duplication when in doubt, and considering consolidation once it appears in three places, is about the right balance

Rather than immediately implementing a shared function just because you found shared code, you also have the option of going back to data design and thinking it through. I would be glad if this article becomes an occasion for that.

At Flyle, Inc., where I serve as VP of Technology, we are currently hiring software engineers.
If this article resonated with you, if you are curious about how we bring these ideas into actual practice, or if you are interested in our business, let us talk in a casual interview.

What It Takes to Be a Tech Lead

baseballyama — Wed, 21 Jan 2026 00:00:00 GMT

At Flyle, where I work, I have been involved in technical decision-making as a tech lead for a long time.

Going forward (or in the near future), there will be more occasions to split up the role or to grow the next person who takes it on. So today, I want to lay out what I think a tech lead needs.

1. Working Backward from Business Strategy

In a for-profit company, product development is not an end in itself; it is a means of driving business growth. Technology selection therefore has to be a decision that aligns with business strategy, not with personal taste or what is currently in fashion.

That requires the ability to use tools like SWOT analysis to lay out your company's strengths, weaknesses, opportunities, and threats, and then translate that into criteria you can actually judge technology choices against.

At Flyle, for example, we defined the competitive advantage of our new product as "being able to analyze large volumes of data quickly." The important part here is not letting the strength stay an abstract slogan, but defining it in a form you can use for design and investment decisions.

Concretely, we defined "large volumes of data" as X0,000 records per tenant, and "quickly" as aggregation completing within roughly X seconds (the actual numbers are not public). This put technology selection in a state where it could be evaluated against performance requirements we had to meet, rather than a vague sense of "fast enough."

We were also, at the time, a startup in a growth phase, in a financial and organizational position where we could invest in a foundation that would strengthen our advantage over the medium to long term, even if it carried some up-front cost. In other words, we were at a phase where we could judge not only "performance in the ideal case" but also the practical question of "is this achievable with the company's current capacity."

With that as the premise, we compared several OLAP options. Snowflake and BigQuery were ruled out on cost. Our analytical queries tend to get complex, and our testing showed that the cost per query execution could run higher than expected. Since this is something we ship as a product, the more usage grows, the more queries get executed. We concluded that, given our situation at the time, it was likely to become too expensive.

Redshift was ruled out on performance. It would have been difficult to meet our performance requirements (aggregating data on the order of X0,000 records per tenant within roughly X seconds), so it could not guarantee the product's advantage.

The result of that comparison was that, at least under the assumptions we had then, ClickHouse was the strongest option for realistically meeting the performance requirements. However, many of our customers are enterprises with strict security requirements. That ruled out ClickHouse Cloud, so we went with self-hosting.

Running it ourselves means that, once you account for availability and redundancy, you need at least several compute nodes, and the infrastructure cost is far from trivial. ClickHouse also has a lot of tuning knobs, which raises the operational burden. In other words, this choice was a decision to knowingly take on cost and operational difficulty in exchange for the benefit of high performance.

We adopted ClickHouse anyway because meeting the performance requirements we had defined was the new product's competitive advantage. Not "because it's popular" or "because it's fast," but being able to speak with accountability to the question "is this cost justified in order to secure the business's competitive advantage" — that, I think, is the first thing a tech lead needs when choosing technology.

2. Overwhelming Ownership

A tech lead's role is not only to make technical decisions. It is to stay responsible, to the end, for the results those decisions produce.

For example, if the business strategy has led us to promise a customer a delivery date for a feature, the tech lead has to drive the team to completion so that promise is kept. And when a critical bug that shakes the foundation of the business occurs, such as data loss, they need to stay with it until the situation is resolved.

This does not necessarily mean staying on the front line of the work yourself. What matters more is leading the team to the goal of "solving the problem" by whatever means necessary, including reallocating team resources, negotiating scope reductions, revisiting priorities, or putting in an unglamorous stopgap fix.

3. Technical Dialogue

A tech lead serves as a technical compass for the team. That does not mean being the most knowledgeable person in every technical area. If anything, given how complex modern stacks have become, it is not realistic for one person to cover every area at production level.

What matters instead is the ability to draw out the knowledge of people who know more than you do, and turn it into the best decision.

In my case, for example, I have depth in the application layer (DB, backend, frontend), but limited hands-on experience building infrastructure. That does not mean I hand off infrastructure design and walk away. I catch up on it myself first, and go into the discussion with people who are strong in infrastructure holding a hypothesis and a design proposal. My style is to pose questions and sharpen my resolution on the topic by learning through the discussion.

There was also a case where we adopted a temporal data model for a feature. I understood the concept, but had no practical experience with it, so it was not among my initial options. A member with more experience proposed it, and I was able to conclude it was the best fit for the requirements. Decisions like that are hard to reach on individual knowledge alone.

The dialogue skill a tech lead needs is not just small talk. It is doing the reading up front even on unfamiliar territory, and coming to the discussion with a hypothesis. And then drawing out the team's strengths while landing on a technical judgment the team can genuinely agree with. I think it is the accumulation of that which becomes a tech lead's value.

4. A Standout Strength

That said, the title "tech lead" presupposes being a technical leader. Taking on the role with no technical strength tends to feel off to the people around you.

So I would recommend building at least one strength that makes people think "this area, I can leave to them." Strength counts for more with depth than with breadth.

In my case, I work as a core team member of the UI framework Svelte, and have relatively deep knowledge of compilers, parsers, and static analysis — the language-toolchain space. On top of that, at Fujitsu, where I joined as a new graduate, I spent a long time working on development standardization for a 300-person project.

Combining those two, I feel my strength is in getting the mechanics of development in order. For instance, when the same point keeps coming up in code review, I add a static analysis rule (writing my own when necessary) and turn it into a mechanism that stops the same comment from recurring, which cuts down review effort.

Likewise, when I felt testing the logic layer on the frontend was a problem, I implemented a custom compiler that extracts just the logic from Svelte components, giving us a foundation for writing tests focused on that logic.

I see these efforts as the product of two things: experience with development standardization made it easier to spot the bottlenecks dragging down team productivity, and knowledge of language toolchains made it possible to turn that into something effective.

A strength does not have to be a flashy accomplishment. Consistently producing value in a specific area and continuing to give it back to the team is what builds credibility and trust as a tech lead.

5. Designing Authority (For Those Appointing a Tech Lead)

The qualities above are largely ones the tech lead can grow through their own effort. What tends to get overlooked, though it is decisively important, is "how much authority the tech lead is given."

The tech lead's role is to set technical direction. But if you hand them the responsibility without the decision-making authority, the team does not function.

For example, if they conclude "we need to invest in infrastructure to meet the performance requirements" but have no budget discretion, and every decision waits on approval, the tech lead cannot set direction. If they have promised a customer "we'll ship by this date" but cannot move scope or reprioritize, then all the ownership in the world leaves them with no lever to pull.

This is not a shortfall in the person. It is a problem of organizational design.

That is why whoever appoints a tech lead has to answer the following questions at the moment of appointment.

Who holds the final say on technology selection
When quality, schedule, and cost collide, who decides the priority
Who can decide to cut scope or delay a release
Who can carve out time to pay down technical debt

If this stays ambiguous, the tech lead becomes someone who carries only the accountability, not someone who decides. Decisions get slower, friction increases, people burn out, and in the end the organization's velocity drops.

Put the other way: when the authority is clearly designed, the tech lead functions as a technical compass, and the team can move forward with confidence.

Appointing a tech lead also means building a structure in which decisions get made.

Summary

The qualities described in this article are what I think as of January 2026, and they should keep getting updated.

Also, since the scope of the "tech lead" role is not strictly defined in the first place, some readers may find parts of this off from their own experience.

I would be glad if you read it as one person's take.