Taste & Craft: A Conversation with Tuomas Artman, CTO of Linear, and Gergely Orosz of The Pragmatic Engineer

A customer requests a feature. An agent can implement it immediately. Should you ship it? For Tuomas Artman, that decision is where AI-assisted development can go wrong: the ability to fulfill every request makes it easier to accumulate functionality until the product becomes confusing. He hopes teams will recognize that danger over the following six to twelve months. Recalling Steve Jobs’s advice, he describes good product development as refusing 999 possibilities to pursue one. Cheaper implementation makes restraint more consequential. Engineering difficulty used to impose a pause in which teams decided whether an idea deserved to exist.

Gergely Orosz challenges the premise: feature factories existed before AI. Their shared experience at Uber supplies the comparison. Competing with Lyft in what Artman describes as a winner-takes-all market meant shipping aggressively, keeping infrastructure alive, scaling, and trying almost everything. He does not want to repeat that hypergrowth experience. AI creates a similar pressure through a different mechanism: a small team, or even one capable person, can reproduce a competitor’s feature set. When functionality becomes easier to match, Artman sees tasteful, high-quality software as a way to retain an advantage.

Orosz makes the challenge concrete with Claude Code and Opus 4.5: if engineers can ship faster, what should Linear ask them to do? Artman’s answer preserves deliberate feature selection. Linear still considers each feature’s place in the user experience and rejects many requests. The work before implementation has not disappeared; much of it was always about understanding what customers actually need.

Linear usually does not ship a request exactly as submitted. Its process moves from a proposed feature to the underlying problem:

1. Talk with customers about what they are trying to accomplish.
2. Group requests that arise from a common cause.
3. Design a solution that addresses that group of needs.
4. Work out the user experience around the chosen functionality.

AI can summarize the incoming requests and suggest groupings. That helps organize the evidence, but deciding which problem to solve and how the result should work still takes time.

Bug repair is one place where Linear is already moving faster. Artman describes bug inflow as effectively constant, while the work needed to repair defects has become easier. Artman reports that 10% of bugs submitted by Linear engineers or customers receive a single-shot AI fix, a pull request, and automatic landing without engineer intervention. The conversation does not specify the measurement window or validation criteria.

He predicts that automated repair could approach 100% over the next few years. That is a forecast, not the current result. The useful division of labor is already visible: delegate tasks with a well-understood desired behavior and little need for fresh product or design judgment, while preserving attention for decisions about what the product should do.

Claude Code becomes a counterexample when the conversation turns from implementation speed to product quality. Artman attributes to Anthropic the claim that Claude wrote all of Claude Code’s functionality. His own criticism concerns the experience of using its CLI and desktop application: he says bugs become noticeable quickly, some interactions feel slow, and behavior can be difficult to understand. These are his observations of the tools at the time of the conversation.

Artman connects those rough edges to competition with OpenAI and the possibility of another winner-takes-all market. The pressure to release more functionality can crowd out the work that makes existing functionality dependable and comprehensible. An agent’s ability to produce code does not itself determine the quality bar applied before that code reaches users.

How do you measure the quality that shipping pressure threatens? Artman recalls five major metrics at Uber. Between them, he and Orosz name revenue, trips taken, ride quality, and time from signup to a first trip; they do not reconstruct the entire set. Revenue dominated the incentives. Measuring the quality of a ride also did not settle whether the application itself was pleasant to use.

Pooled rides illustrate the gap. Artman is unsure whether Uber or Lyft introduced pooling first, but his argument does not depend on that order. A less expensive ride can attract demand and increase revenue even if the surrounding experience is rough. When no other platform offers an equally inexpensive option, customers have a reason to tolerate those rough edges. Engineers may care deeply about polish, yet the business metric rewards the new capability without isolating the value of its execution.

Artman remembers that care being explicit when he joined Uber around 2012. In an early pull request, he changed the map margins around a central pole showing the car’s estimated arrival time. An early iOS engineer reviewed the change and measured the pole’s position. Artman recalls being told it was two pixels off, then moving it up one pixel. The lasting lesson was the attention: another engineer was willing to inspect and defend a detail that most users would never consciously notice.

As the team grew and revenue incentives took precedence, shipping more features became the stronger organizing force. Artman’s theory is that quality becomes commercially visible once competitors offer similar functionality at similar prices. A customer trying the alternative may find it more comfortable or feel that a car arrives faster, even when the underlying service is equivalent.

Those comparisons may happen only occasionally. Users can drift away over time, making the effect difficult to capture in a single A/B test of a quality improvement. Artman explicitly revises the image of a competitor leapfrogging a product: the danger is being slowly overtaken. That delayed feedback is part of his rationale for investing in Linear’s quality before a revenue metric demands it.

Linear’s Quality Wednesdays make that investment a recurring engineering practice. Orosz describes joining a remote show-and-tell planned for 30 minutes: roughly 25 engineers presented fixes in about 37 minutes, with each presentation under two minutes. The changes ranged from a one-pixel adjustment to improvements in backend efficiency.

Artman traces the practice to an offsite roughly three or four years earlier and a small interaction rule engineers kept overlooking. Artman specifies an instantaneous hover highlight followed by a 150-millisecond fade-out when the pointer leaves. The entry makes the interface feel responsive; the exit makes it feel smooth. This asymmetry can be expressed directly in CSS:

.action {
  background-color: transparent;
  transition: background-color 150ms;
}

.action:hover {
  background-color: rgb(128 128 128 / 18%);
  transition-duration: 0ms;
}

On pointer entry, the hover state removes the transition delay between the two colors. On exit, the base rule restores the fade. The colors are incidental; the directional timing is the behavior Artman wants engineers to notice.

Repeated reminders were not teaching that attention reliably. At the offsite, Artman brought the team together to inspect a small view-options menu for an hour, expecting them to find missing highlights. Artman says the inspection uncovered about 35 problems in that single menu. The exercise exposed details he had not seen himself and suggested that the rest of the application contained many more opportunities. At the time of the talk, Artman estimates that Linear had fixed 2,500–3,000 small quality details.

The essential rule is that each engineer must discover a problem rather than receive an assigned one. Initially, finding improvements was easy. As obvious imperfections disappeared, discovery became harder, but the weekly obligation kept people looking. While building an unrelated feature, an engineer would notice something worth bringing to the next Wednesday meeting.

That changes the practice from a cleanup ritual into training. Artman says engineers who continually look for small quality problems also introduce fewer of them in new work. The discovery requirement builds the attention that prevents regressions. Orosz recommends trying the practice at a small startup; Artman responds that larger startups have even more reason to adopt it.

Linear’s zero-bugs policy addresses reported defects through a separate process. It does not mean that software never has bugs or that every report is repaired instantly:

1. An agent immediately assigns the report to the likely creator of the defect or someone familiar with the affected area.
2. The assigned bug becomes that engineer’s highest priority. It is the first work to pick up from My Issues.
3. The engineer fixes it or explicitly decides against a fix when the cost is disproportionate to the impact.

Artman’s example of the last case is a difficult defect affecting only one in 100,000 users. The commitment is to prompt ownership and a decision, rather than indefinite storage in a backlog.

His reasoning starts with a steady inflow of defects from ongoing development. A team postpones repair until the product feels bad enough—perhaps, in his illustrative scenario, when 500 bugs have accumulated. It then has to repair bugs at the incoming rate just to stop the backlog growing. Delaying the work by months has not removed that continuing workload. If a team intends to keep up eventually, clearing the existing backlog creates the opportunity to do the same repair work promptly.

Artman reports that Linear paused new functionality for approximately three weeks to clear its bug backlog. He reports subsequent bug fixes within seven days, usually in two or three hours, subject to the policy’s explicit option to decline a fix. The customer experience changes with that turnaround: someone reports a problem, receives an email a couple of hours later, and can refresh the browser to get the correction.

An assigned bug does not count as a Quality Wednesday contribution. It is a defect to resolve; Wednesday still requires an independently discovered improvement. The distinction preserves both habits: respond to known failures and actively look for ways the product could feel better. With AI helping locate and repair defects, Artman argues that more companies should adopt the zero-bug approach.

Orosz pushes back on the division between AI and quality. Agents can write unit tests and operate feedback loops; should those abilities not produce better code, features, and interfaces? Artman distinguishes those capabilities from taste: judging whether an interface serves its particular purpose and understanding how a person feels while using it. He considers that a remaining limitation of current agents, while leaving open whether future systems will overcome it.

His concrete example is time. An agent inspecting screenshots or the DOM sees what he describes as a timeless representation of an interaction. It can retrieve advice about hosting a Next application on Vercel or using caching, and it can recognize that one second is numerically shorter than two. But, in Artman’s account, that is different from experiencing the frustration of waiting two seconds after a click and judging whether the delay is acceptable in context.

Animation exposes the same distinction. Artman describes an experiment that Linear design engineer Emil had shared on X the previous day: agents implemented pop-ups, button highlights, and moving elements, then Emil manually refined the results. The functionality was present in both versions. What changed was the feeling of the motion—an easing choice, a duration that was too long or too short, or an entrance that did not feel natural. To Artman, those refinements demonstrate why implementing the requested effect and choosing the right effect remain different skills.

Linear tries to hire people who already want to build beautiful, high-quality software. Its synchronization engine and infrastructure create substantial technical challenges, but most engineers focus on product functionality and customer needs. The hiring process is designed to observe that orientation in practice.

Artman describes a paid, full-week work trial for every employee, usually centered on a greenfield project, product, or feature. Some trial work ships at the end of the week. The evaluation is broader than implementation: can the candidate determine what is needed and drive the work from beginning to end?

Orosz raises the cost to candidates who cannot or will not take a week away from their existing work. Artman accepts that exclusion and interprets unwillingness to participate as a lack of desire to join. Asked how the results compare with Uber’s conventional five- or six-interview process, he reports very few hiring misses at Linear. Looking back at those misses, he says the team sometimes had reservations but hired anyway. The trial reveals more working behavior, while imposing a substantial participation requirement.

Once engineers join, customer context is readily available:

• Open customer channels: Slack channels with Linear’s large customers are accessible to employees, who can read requests and problems directly.
• Recorded conversations: Customer meetings across customer experience, support, and product management are recorded.
• Searchable detail: Interesting moments are tagged so an engineer can search for a feature and hear what customers said about it.

These practices expose engineers to the evidence behind a request, rather than only the resulting task.

That access matters more as Linear’s customers diverge from its own team. The product began as something its engineers built for themselves. It now serves large corporations and enterprises with needs a smaller company does not share. Internal usage alone cannot reveal those requirements; engineers have to learn from the people who actually have them.

Asked how the engineering role might change over the next year, Artman stretches the horizon: he looks back over four years of AI progress and imagines another four ahead. His prediction depends on capabilities continuing to improve rapidly without hitting a wall, which he acknowledges is uncertain. Under that condition, he expects less demand for engineers whose contribution is merely moving data from one place to another, and continued demand for people who understand customer needs, recognize a good feature, and judge a good user experience.

He describes engineers becoming more like small-scale product managers: talking with customers, deciding what functionality matters, and implementing it. Orosz points out the expanding job description. Programmers went from one language to several, then absorbed QA and DevOps responsibilities; now product and customer support seem to be joining the list. Artman jokes that the other work has dropped away, leaving the product work. The exchange captures the tension in the forecast: automation can reduce implementation effort while increasing the importance of owning the outcome.

You do not need a product-engineer title to begin developing that judgment. Artman’s closing advice is to move closer to customers in your current company, or build something yourself. Start with a need you understand personally, implement a solution, and release it. The first outside users create the next learning opportunity: their experience tells you whether you solved the right problem, not just whether you successfully built the feature.

For a foundation in interface design, he recommends Apple’s Human Interface Guidelines. Reading established guidance complements the practical loop of making something, putting it in front of people, and learning what they need. Faster implementation makes that loop more accessible; the judgment develops through paying attention to what happens after someone uses the result.