I say “imperfect” because the goal isn’t to get it right. The goal is to create motion. In ambiguous moments, the problem isn’t lack of quality direction - it’s lack of any direction. The plan’s job is to break the stalemate.

So, start simple. Write down:

• What are you going to do?

• What’s your team going to do?

• What do you expect to achieve by the end of the quarter?

• What are you explicitly not doing, and why?

Even if the plan is a weakly held belief, it’s a starting point. Action creates information.

Next, share it. Send it to the people who could give you input but haven’t: a manager, a peer, a cross-functional partner. Do it in a lightweight, non-blocking way. Something like:

“Hey, just wanted to share what I’m planning for the team this quarter. Would love your input if you have thoughts. I’m locking this in Friday.”

Then, wait. One of two things will happen.

1. They’ll rubber-stamp it. They’ll appreciate the initiative, maybe skim it, maybe even echo your clarity upward. Great, you now have alignment and a path forward.

2. You’ll trigger a strong reaction. This is the gold. The plan creates the contrast that was missing. Suddenly they’ll say, “No, not that, this.” That’s the moment you were waiting for. Now you have something to debate, and the discussion will be concrete, fast-moving, and productive.

The act of writing down an imperfect plan forces others to clarify their thinking. It puts a clock on their opinion. It changes the conversation from “What should we do?” to “Should we do this or that?”

I’ve seen this work across teams and roles. PMs do it when product direction is vague. Engineers do it when requirements are fuzzy. Even execs do it when strategy is drifting. In every case, the draft plan functions like a forcing mechanism - it transforms ambiguity into energy.

Action creates information. When no one is telling you what to do, write the plan anyway. The act of doing so will often draw out the direction you were missing.

Eventually, though, you hit a wall. The AI-generated code grows quickly, and small features suddenly become thousands of tokens long. Errors stack up, causing endless debugging loops. Your progress slows to a crawl.

You stop to think: your app seems to work—at least on the surface. Even the documentation feels unfamiliar, like someone else's shallow understanding of your project. It reminds you of finding a disappointing two-star GitHub repo. You wonder about the app’s structure, how parts connect, and how it can grow.

The core issue here is losing context. LLMs might manage external details well, but human understanding quickly fades when you're not actively involved with the code.

Previously, gaining context happened naturally. Hours of manual coding forced you to learn every small detail. You wrote tests, fixed logic errors, thought about state management, and carefully chose endpoint designs. You planned for future growth and built thoughtful abstractions. This careful involvement built a strong mental map of your project, making navigation easy, even months later.

Today, code created by LLMs can feel strange. Claude, your AI helper, "knows" the code briefly, but only on a shallow level. When the task ends, its brief understanding disappears. Both you and Claude approach the code fresh every time, losing all context.

Losing context matters greatly. Context makes engineers uniquely valuable. It’s why even highly skilled new engineers spend months "ramping up" when joining a new project. This period is about deeply learning the specific details, patterns, and risks of the project. Only after gaining this deep understanding can engineers contribute strong opinions, important improvements, and good strategic decisions.

Without context, engineers struggle to guide architecture or solve difficult problems, significantly reducing their value. Agentic coding risks taking away engineers' most important asset: accumulated context. This loss reduces engineers to passive reviewers, disconnected from the detailed knowledge necessary for thoughtful design and innovation.

The closest experience I have to agentic coding is when I moved from being an individual contributor to an engineering manager. In management, my hands-on involvement with the code dropped a lot. My understanding became surface-level, based mostly on short conversations, quick reviews of pull requests, and occasional bug checks. My focus shifted from technical details to people-focused concerns—a valuable but fundamentally different skill.

That's exactly how I feel when vibe-coding. I'm supervising an eager intern who quickly produces code that mostly works. Neither of us deeply understands the structure or inner workings of the application.

Some people believe future AI models will soon write flawless code. Upcoming models like Claude 5 or 6 will certainly improve. But regardless of how advanced AI gets, humans must remain the architects and final decision-makers. Security, accountability, and strategic choices require engineers to keep ultimate responsibility. Preserving context is therefore crucial. Without it, we risk blindly approving AI-written code without true oversight.

Maintaining context requires deliberate efforts. Engineers need to regularly set aside uninterrupted time to deeply read and understand AI-generated code. Writing some code yourself, even occasionally, helps embed key details in your mind. Co-writing interactively with AI, similar to traditional pair programming, ensures continued engagement. Keeping code changes small and easy to review, even if AI quickly generates larger updates, is important.

Ultimately, the engineer—not the computer—is responsible for the codebase. Keeping context isn’t just helpful; it’s essential. As agentic coding grows more common, actively investing in human understanding will become a major advantage. Engineers must protect and strengthen their roles as knowledgeable caretakers of their projects. Without deep context, engineers risk becoming passive watchers, overseeing large, unfamiliar codebases without true mastery or meaningful control.

In brief, these principles are:

1. Clear, Inspiring Mission – A bold “why” galvanizes teams around a purpose larger than themselves.

2. Talent Density and Willingness to Let People Go – Selective hiring and pruning underperformance creates a high-achieving core.

3. Uncompromising Performance Standards – A refusal to accept mediocrity compels continual improvement.

4. Aggressive Goals and Tight Deadlines – Urgency and ambition spark focused, innovative sprints.

5. Culture of Accountability and Peer Pressure – Transparent progress and open feedback keep everyone on their toes.

6. Meaningful Rewards and Recognition – Aligning incentives—financial or symbolic—fuels sustained motivation.

If I were to list these even more concisely: mission, talent, standards, deadlines, accountability, and rewards.

Of course, these elements work best when supported by additional factors like autonomy, strong leadership by example, and team camaraderie. But first things first: let’s start with the bedrock principle—crafting a mission so compelling that people can’t help but pour themselves into it.

1. Clear, Inspiring Mission

A powerful mission is the foundation for any high-octane culture. It articulates exactly why the team’s work matters and gives a unifying sense of purpose. When people believe they’re contributing to something truly meaningful—even “impossible”—they tend to show up with more passion, creative energy, and willingness to tackle tough obstacles. Three classic examples illustrate how a clear mission can spark extraordinary commitment:

NASA’s Apollo Program: “We Choose to Go to the Moon”

In 1961, President John F. Kennedy challenged NASA to land a person on the Moon by the end of the decade. This was more than a technical mandate—it was an inspiring national mission that captured imaginations around the world. At its height, Apollo involved roughly 400,000 people racing against an audacious deadline. Engineers worked nights and weekends, driven by the sheer grandeur of the goal: “We choose to go to the Moon…not because it is easy, but because it is hard.” That resonant message gave every late-night test, every engineering fix, a larger meaning. In just eight years, NASA overcame enormous hurdles to achieve the seemingly impossible: Apollo 11’s Moon landing in 1969. The bold clarity of the mission (“Moon by ’69”) galvanized an entire generation of scientists and engineers.

SpaceX: Making Humanity Multi-Planetary

Privately, Elon Musk’s space venture might have remained niche—but publicly, he declared that SpaceX exists to make humanity a multi-planetary species. This breathtaking vision—colonizing Mars—is more than a corporate tagline; it’s a rallying cry. The company actively seeks out “extremely passionate” people, as one former engineer put it, who want to devote long hours and emotional energy to pushing rocket technology forward. Nobody’s forced to do it; they just believe in that bigger story. SpaceX’s improbable achievements (like routinely landing orbital-class rockets) flow from that sense of grand purpose: employees feel they’re shaping the future of civilization, not just punching a clock.

Bell Labs: “Invent the Future”

Bell Laboratories in the mid-20th century didn’t chase a single “moonshot,” but it operated under a sweeping imperative: advance communication and information technology for the future. Management concentrated brilliant minds in one place and let them roam free on big problems—transistors, lasers, satellites, information theory. Bell Labs historian Jon Gertner highlights how this overarching mission (combined with autonomy and mastery) fueled relentless innovation. Researchers weren’t just improving phone lines; they believed they were inventing tomorrow’s world. That belief proved self-fulfilling: the breakthroughs from Bell Labs formed much of modern computing and telecommunications.

Why It Works

When a mission is both ambitious and crystal-clear, people see how their efforts connect to a larger narrative. They volunteer extra hours and mental bandwidth not out of obligation, but out of genuine excitement to be part of something historic. As JFK put it, “organize and measure the best of our energies and skills”—that’s exactly what a compelling mission accomplishes: it unifies and amplifies human potential. If you want a team that doesn’t need “forcing” to work hard, start by giving them a great reason to do it.

2. Talent Density and Willingness to Let People Go

A brilliant mission can attract people, but it’s the composition of the team—and the refusal to tolerate mediocrity—that truly keeps performance sky-high. Put simply, high talent density occurs when nearly everyone on the team is an “A player.” Companies that maintain this standard tend to outperform competitors, because every member is capable, motivated, and raising the bar for each other. Conversely, allowing underperformance to linger saps morale and momentum.

Apple: “A-Players Hire A-Players”

Steve Jobs famously believed that “A-players hire A-players; B-players hire C-players.” At Apple, he insisted on recruiting only the most talented, driven engineers and designers—often in small teams—and unhesitatingly let go of those who didn’t measure up. The result? Tightly knit groups of top performers who produced revolutionary products like the Macintosh and the iPhone, despite lean headcounts. Jobs observed that high-caliber people want to work alongside other top talent, and they resent mediocrity. By protecting that elite environment, Apple created a decades-long pipeline of world-changing devices.

Netflix: “Adequate Performance Gets a Generous Severance”

Netflix codified a similar attitude in its culture deck, announcing bluntly that “adequate performance gets a generous severance.” This wasn’t designed to be cruel; rather, it was about creating a “dream team” of standout performers who feed off each other’s excellence. Executives apply the so-called “keeper test”: “If this person resigned, would you fight to keep them?” If the answer is no, Netflix parts ways—kindly, but decisively. This policy keeps talent density high, ensuring that everyone shares a common drive. In that environment, the mere presence of underperformers becomes a noticeable drag, so leaders address it quickly. The upside is a team that’s consistently top-tier—and thus more motivated to stay.

Bridgewater Associates: Radical Transparency and “Up-or-Out”

Hedge fund Bridgewater, led by Ray Dalio, takes this even further with its “radical transparency.” Every meeting is recorded; everyone constantly rates each other’s ideas and performance. It’s a crucible that quickly reveals who’s thriving and who isn’t. Underperformers or those who can’t handle the direct feedback leave rapidly—sometimes by choice. Those who remain often describe themselves as “intellectual Navy SEALs,” proud to be part of an ultra-elite environment. Bridgewater’s track record as the world’s largest hedge fund testifies to the power of rigorous talent curation.

Why It Works

1. Top Talent Attracts More Top Talent – A-players love learning from and competing with peers at their level.

2. Eliminating Complacency – When everyone on the team is strong, slackers or weak contributors stand out immediately.

3. Confidence and Momentum – People in high-talent groups push each other upward; no one wants to be the limiting factor.

It can feel harsh, but when done with fairness and transparency—providing generous severance, honest feedback, and clear performance metrics—removing mediocrity lifts morale. Talent density becomes a self-reinforcing engine of motivation.

3. Uncompromising Performance Standards

Even a dream team can drift unless there’s a culture-wide expectation of excellence. When leaders insist on the highest standards—and back that up by refusing to accept shoddy work—teams rise to meet the bar. Over time, “this is how we do things” morphs into genuine pride, fueling continuous improvement.

Amazon: “Insist on the Highest Standards”

Amazon encodes high standards in one of its core leadership principles: “Leaders have relentlessly high standards—many people may think these standards are unreasonably high.” Jeff Bezos believed “good enough is never enough,” whether in warehouse operations or software reliability. Teams must root out problems permanently so they “stay fixed,” with no passing of defects downstream. This mentality helped Amazon become a logistics and e-commerce juggernaut; the unwavering bar for speed and quality forces constant innovation. Warehouse employees cut shipping times to near-zero; engineers fine-tuned AWS to handle massive workloads. The habit of always pushing for better results is baked into Amazon’s DNA.

Pixar: “Quality Is the Best Business Plan”

Under Steve Jobs’ ownership, Pixar exemplified a refusal to ship half-baked films. A rigorous peer-review system—the “Braintrust”—supports this: if a story isn’t working, it gets torn apart and rebuilt, no matter how far along production is. Pixar famously scrapped and redid huge chunks of Toy Story 2 late in the schedule to ensure it met their creative bar. While that process demands long hours and repeated rework, it also produced an unprecedented streak of award-winning animated films. Pixar’s teams know that every department—lighting, animation, narrative—must meet the same uncompromising standards. The result is a studio where “excellence or bust” is second nature.

Toyota: “Stop the Line” Culture

Beyond tech, Toyota’s legendary lean manufacturing sets near-flawless quality standards. On an assembly line, any worker can pull an Andon cord to halt production at the slightest defect. Instead of sending flawed parts downstream, Toyota addresses issues on the spot, preserving a “zero defects” ethos. This constant vigilance creates discipline and a spirit of continuous improvement—every shift ends a bit more efficient. The payoff? Toyota became world-renowned for reliability, reshaping global automotive standards. The lesson for tech teams is clear: when excellence is the only option, people proactively prevent errors rather than patching them later.

Why It Works

1. Shared Accountability – If the bar is uniformly high, everyone feels responsible for meeting it.

2. Positive Feedback Loop – High standards → better outcomes → team pride → even higher standards.

3. Long-Term Competitive Edge – Consistent excellence builds trust in your product or brand, which pays dividends.

Uncompromising standards do require balance—teams need enough support to hit those lofty goals without chronic burnout. But when done right, they elevate the entire operation. It’s not about perfection; it’s about refusing to settle for “just okay.”

4. Aggressive Goals and Tight Deadlines

Even highly talented teams need a tangible spark to mobilize their best efforts. Aggressive goals—paired with firm deadlines—provide that sense of urgency. When the clock is ticking and the target seems “impossible,” resourcefulness and intensity often skyrocket. In short bursts, this so-called “crunch” can yield massive leaps forward.

Tesla: “Production Hell”

Elon Musk’s Tesla Model 3 ramp in 2017–2018 is a textbook example. Musk publicly promised that Tesla would hit 5,000 Model 3s per week by Q2 2018, a figure the company had never approached. As the deadline neared, employees pulled 24/7 shifts, Musk himself slept on the factory floor, and Tesla even erected a makeshift assembly line in a tent to boost throughput. The team eventually just hit the goal—literally on the last day (and a few hours past midnight). Many criticized the chaos and burnout, but it’s undeniable that the looming, very public deadline spurred dramatic innovation. The company solved bottlenecks in weeks or months that might otherwise have taken years.

Microsoft in the ’80s and ’90s: “Ship It or Else”

Early Microsoft had an intense “ship it” culture under Bill Gates. Products like Windows and Office were assigned release dates—and teams were expected to meet them, no matter the all-nighters required. Gates himself was famously relentless, memorizing employees’ license plates to see who left early. While this fostered a sometimes harsh environment, it pushed small, brilliant teams to deliver on tight schedules, making Microsoft’s OS and productivity suite dominant worldwide. The lesson? An unmoveable release date can light a fire that focuses everyone on delivering core features, fast.

Skunk Works: “Impossible” Aircraft in Record Time

Lockheed Martin’s Skunk Works, led by engineer Kelly Johnson, tackled ultra-ambitious aviation projects—like building the U-2 spy plane in just eight months. Johnson’s approach was to keep teams lean, cut red tape, and impose (seemingly) unrealistic timelines. This forced rapid prototyping, minimal bureaucracy, and a laser-like focus on the critical path. The result: multiple groundbreaking aircraft delivered years ahead of normal schedules. The Skunk Works model highlights how urgent deadlines, combined with autonomy, can supercharge inventive thinking.

Why It Works

1. Intense Focus – With the clock ticking, teams prioritize only what matters.

2. Crossing Psychological Barriers – Ambitious goals trigger creative problem-solving that “normal” timelines wouldn’t.

3. Morale Boost on Achievement – Hitting a tough deadline gives a powerful team-wide sense of accomplishment.

However, perpetual crunch is unsustainable. Effective leaders deploy aggressive goals in carefully timed intervals—ensuring the payoff (learning, celebration, sense of victory) balances the stress. Used wisely, deadlines can catapult a team from “good” to “astonishing.”

5. Culture of Accountability and Peer Pressure

In high-performing cultures, accountability isn’t just top-down—it’s woven into peer relationships. When progress is visible, and people know their coworkers will notice lapses, there’s a natural nudge to show up at your best. It’s less about fear and more about not wanting to let the team down.

Facebook’s “Hacker Culture” and Transparency

Early on, Facebook championed a hacker ethos: “Move Fast,” “Keep Shipping,” and plastered motivational posters around the office. Internally, engineers had access to each other’s code repositories, and weekly Q&As with Mark Zuckerberg made information flow extremely open. This setup fostered a sense that everyone knew what everyone else was working on. Shipping a useful feature on Friday led to public kudos and admiration; slacking off or failing to ship had no real hiding place. That kind of peer visibility created a healthy (and sometimes intense) pressure to deliver results—and do it quickly.

Stripe: Radical Internal Visibility

Payment startup Stripe takes transparency even further: nearly all project emails are CC’d to open mailing lists so anyone can track them. Team dashboards show who’s working on what, and an IRC bot regularly asks engineers for status updates, posting them company-wide. This public tracking isn’t meant to shame anyone; rather, it allows people to see where they can jump in and help. But it also gently reminds everyone: “We’re counting on you—how’s it going?” That ambient awareness incentivizes engineers to stay productive and maintain momentum.

Atlassian: Peer Code Reviews and “ShipIt” Days

Atlassian, known for developer tools like Jira and Bitbucket, embeds accountability through mandatory peer code reviews—nobody merges code without a colleague’s green light. This practice keeps quality high while also encouraging collaboration. They also hold quarterly “ShipIt” hackathons where teams demo projects to the entire company. Nobody wants to stand up and demo something half-baked, so they work intensely to make it cool. Public demos harness the fun side of peer pressure—showcasing your best work to people you respect.

Why It Works

1. Social Motivation – Humans naturally care about their reputation among peers.

2. Shared Visibility – Open progress tracking means issues get noticed early, and credit is given where it’s due.

3. Mutual Support – Colleagues can rally around bottlenecks or problems, reducing the chance of quiet floundering.

This kind of peer-driven accountability tends to foster both performance and camaraderie. People push each other in a supportive (if sometimes intense) environment. Combined with the previous principles—like tough goals and high standards—it helps a team stay aligned and keep delivering, day in and day out.

6. Meaningful Rewards and Recognition

Even the most mission-driven team appreciates tangible proof that their efforts matter—whether in the form of financial upside, status, or simple public kudos. Meaningful rewards align personal goals with team goals, fueling sustained motivation rather than just short-term bursts. When set up correctly, this is a powerful lever to keep a high-performing team fully engaged.

Google: Transformative Equity

In its early days, Google couldn’t match competitors’ salaries, so it offered substantial stock options. By the time of Google’s 2004 IPO, thousands of employees—and even support staff like the company’s chef—suddenly owned life-changing stakes in the business. This windfall converted a “job” into an entrepreneurial pursuit: every bug fix or infrastructure improvement could boost Google’s success and each engineer’s own net worth. That alignment led to remarkable dedication. Employees say the “startup mindset” lingered well beyond the IPO because everyone felt like owners, not clock-punchers.

Netflix: Top-of-Market Salaries

Rather than equity, Netflix focuses on paying top-of-market cash compensation. CEO Reed Hastings believes a single all-star outperforms multiple merely “good” people, so Netflix invests heavily in those top performers. Coupled with the practice of quickly letting go of “adequate” performers (Principle 2), Netflix’s approach means those who pass the high hiring bar see direct, significant financial rewards. On top of that, the culture emphasizes direct praise for standout work—recognizing individuals publicly. The result: employees feel deeply valued and push themselves to maintain “all-star” performance.

Sales Commissions & Leaderboards

On the sales side, many enterprise tech firms use clear, hefty commissions or contests (think “President’s Club” trips) to drive incredible effort around quarterly targets. There’s a reason this model is common: “hit your number, and you get a life-changing bonus.” The extrinsic lure of big money is reinforced by the public recognition of “top closer” status. While not every role lends itself to commission structures, the takeaway is universal: if people can see a direct link between working harder (or smarter) and a meaningful reward, they tend to push boundaries.

Why It Works

1. Alignment of Interests – Personal success is tied to team or company success.

2. Public Celebration – Earning visible kudos from peers or leadership satisfies our innate desire for recognition.

3. Sustained Motivation – Over time, consistent and fair rewards (financial or otherwise) keep people engaged.

It’s important to combine extrinsic rewards with the intrinsic motivations from the earlier principles—such as mission, mastery, and camaraderie. When both heart (purpose) and wallet (incentive) point in the same direction, teams can sustain a high effort level without constant prodding.

Additional (Supporting) Principles

The six main pillars—mission, talent density, high standards, aggressive goals, accountability, and rewards—go a long way toward building a culture of extraordinary motivation. Yet there are other threads that consistently show up in top-performing teams. Think of these as force multipliers that amplify all the previous principles.

Autonomy and Ownership

Empowering talented people to decide how to achieve their goals can supercharge creativity and drive.

• Google’s 20% Time – Not only did it produce breakthroughs like Gmail; it signaled trust in engineers to pursue big ideas.

• Stripe’s Self-Managed Teams – The company gives small squads wide latitude to figure out solutions. That freedom cultivates initiative and a personal sense of accountability.

Opportunities for Mastery and Growth

Top performers love pushing themselves to master new skills. Companies that provide challenging projects, mentorship, and a learning culture see employees double down on their work.

• Pixar – Constantly evolves animation technology (like new hair or water simulations), so each film pushes artists to break new ground. That quest for mastery keeps motivation high.

• Open Source Projects – Many contributors work tirelessly for no direct pay, driven by the desire to learn, improve, and earn peer respect.

Strong Leadership and Leading by Example

Whether it’s Elon Musk sleeping on the factory floor or Steve Jobs agonizing over product details, leaders who “walk the talk” inspire teams to follow suit.

• JFK’s Apollo Rally – A clear, galvanizing speech set the tone for NASA’s entire mission.

• Founders Staying Hands-On – Many successful startup founders keep direct involvement in key areas, showing that no one is “above the work.”

Camaraderie and Team Spirit

Ultimately, many people work hardest for each other. Teams that genuinely like and trust each other build deep commitment—and that human bond fuels extra effort.

• SpaceX Launch Days – Employees describe an almost “family” atmosphere, forged by mission stress and shared triumphs.

• High-Performing Sports Teams – From the All Blacks (rugby) to NBA champions, players often cite strong locker-room bonds as a key to success.

These supporting factors reinforce the central cultural engine. Autonomy, personal growth, leadership role models, and genuine camaraderie help each principle—from high standards to big deadlines—land more effectively.

In conclusion

Depsite what individual annecdotes might imply, there’s no one “trick” to creating a high-output, deeply motivated team. It’s about combining several cultural levers, each reinforcing the others:

1. Mission – An inspiring “why” that compels people to go above and beyond.

2. Talent Density – Top performers who push each other, with no room for dead weight.

3. Uncompromising Standards – A shared expectation of excellence in every facet of the work.

4. Aggressive Goals and Tight Deadlines – Strategic bursts of urgency that spark innovation.

5. Culture of Accountability – Transparency and peer visibility, so everyone feels both supported and observed.

6. Meaningful Rewards – Tangible payoffs and recognition to keep the long-term fire burning.

Enhance all of this with autonomy, growth, leadership by example, and genuine team spirit, and you have a blueprint for extraordinary achievement. Of course, these principles can be taken to unhealthy extremes—burnout is real, and cultures can become toxic if overly rigid. But when applied thoughtfully, they create an environment where people want to do great work. They find purpose and pride in being part of something bigger, and that sense of meaningful challenge is exactly what unlocks the “impossible.”

If you’re aiming to build or strengthen such a culture, start by examining which principles you already excel at and which ones are underdeveloped. Even incremental shifts—raising the talent bar, clarifying the mission, celebrating the best work—can have a dramatic effect on your team’s energy and output. Over time, these cultural choices compound, and you’ll see firsthand the difference between a group that’s merely “good enough” and one that consistently operates on a higher plane.

The Early Web: Presentational HTML and Table-Based Layouts

Let’s go way back to the beginning. In the mid-1990s, styling web pages was a wild west. Early HTML offered almost no separation of style and content – developers used presentational tags like <font> and attributes like bgcolor to tweak appearance. Layouts were often achieved with nested HTML tables and 1px transparent spacer GIFs. This “tag soup” approach was messy and hard to maintain, but at the time it was the only way to control design in browsers. As one web designer from that era quipped, when asked how to change fonts or layouts on the web, “Sorry, you’re screwed”​

– in other words, HTML alone couldn’t do it.

The idea of Cascading Style Sheets (CSS) emerged in 1994. Håkon Wium Lie, working at CERN, proposed a stylesheet language to decouple presentation from HTML content.​ This concept gained traction, and by December 1996 CSS Level 1 became a W3C recommendation. CSS promised a better way: authors could write rules in a separate stylesheet to control layout, typography, and colors, while keeping HTML semantic and focused on structure.

Adoption of CSS was slow at first. Browser support in the late ’90s was incomplete and inconsistent – the era infamously known as the “Browser Wars.” Internet Explorer 3 (1996) and Netscape 4 (1997) both introduced CSS support, but each had bugs and proprietary quirks​. Because CSS was “far from a best practice” due to spotty support​, many developers stuck with what worked: HTML tables for layout and deprecated tags for styling. In 1996, designer David Siegel even published “Creating Killer Websites,” a guide advocating table layouts and spacer hacks to achieve precise designs​. By the late ’90s, most sites were still using table-based layouts and inline styling hacks; CSS existed, but it wasn’t yet dependable across browsers​.

Early 2000s: CSS Matures and Table Layouts Fade

As the web community pushed for standards, the early 2000s saw a turning point. Web standards evangelists like Jeffrey Zeldman championed the separation of content and presentation. In 2002, major websites began to prove that CSS-centric design was not only possible but advantageous. Wired magazine’s web team, led by Douglas Bowman, launched a complete CSS-based redesign in 2002, at a time when virtually no other large site was using CSS for layout​. Just months later, ESPN followed with its own CSS-driven redesign​. These high-profile launches demonstrated that modern, complex layouts could be achieved with standard CSS instead of <table> grids. The benefits were immediately clear – leaner pages, easier updates, and a cleaner separation of concerns.

In 2003, the movement gained further steam. Zeldman published “Designing with Web Standards,” a book that became a manifesto for moving away from tag-soup HTML. Around the same time, Dave Shea’s CSS Zen Garden (2003) became a revelation: it showcased dozens of beautiful designs all achieved by styling the exact same HTML differently. This proved the power of CSS in capable hands, and convinced many developers that it was time to ditch old hacks. As historical accounts note, CSS Zen Garden “went a long way towards convincing folks it was time for standards.” By the mid-2000s, the web industry was firmly embracing semantic HTML and external CSS. Table-based layouts began to disappear, relegated to the history books of “how we used to do it.”

Several technical advancements around this time helped CSS turn the corner from novelty to norm:

• Better Browser Support: Internet Explorer 6 (2001) and 7 (2006), Firefox (from 2004), and other browsers gradually improved their CSS compliance. The Web Standards Project (WaSP) pressured vendors to fix CSS bugs​. Consistent support for CSS2 features (like the box model, positioning, etc.) meant developers could trust CSS more.

• CSS2 and Early CSS3: CSS Level 2 became a W3C Recommendation in 1998​, adding features like absolute/relative positioning and media types. In the 2000s, work began on “CSS3” – an iterative evolution split into modules (selectors, color, etc.). New capabilities like media queries (for responsive design) and improved selectors started appearing, making CSS even more powerful for layouts.

• Community Resources: Blogs and sites like A List Apart shared techniques for CSS layout, while “CSS resets” (like Eric Meyer’s Reset CSS) emerged to normalize styles across browsers. Frameworks like Blueprint CSS (2007) or YAML provided pre-made grid systems using CSS, easing the transition from tables to CSS-based grid layouts.

By the late 2000s, using semantic HTML with CSS for layout and design was considered a best practice. The dreaded <font> tag was retired, and CSS-based, standards-compliant design had become the new normal. This era set the stage for the next wave of innovation: making CSS easier to write and maintain for increasingly complex projects.

The Rise of CSS Preprocessors (Late 2000s)

As websites grew more complex, developers began to hit the limits of vanilla CSS. Large style sheets became difficult to maintain. CSS has no native variables, functions, or math, and its syntax, while simple, can lead to repetition. To address these pain points, the late 2000s introduced CSS preprocessors – languages that extend CSS with programming-like features and compile down to standard CSS.

Sass (Syntactically Awesome Style Sheets), released in 2006, was the first major preprocessor. Created by Hampton Catlin and further developed by Natalie Weizenbaum, Sass introduced features like variables, nested selectors, mixins (reusable chunks of CSS), and functions for color manipulation and calculations​. Sass initially had its own indented syntax, but later added an “SCSS” syntax that looked more like traditional CSS, making adoption easier. In practice, Sass allowed developers to keep their styles DRY (Don’t Repeat Yourself) and better-organized. Need to use the same color in multiple places? Define a variable once. Want to lighten or darken a color? Use a built-in function. Such capabilities were revolutionary for the time.

Hot on Sass’s heels, Less (Leaner Style Sheets) was released in 2009 by Alexis Sellier​. Less had a similar feature set (variables, nesting, mixins) but could run in the browser via JavaScript or on the server, which lowered the barrier to entry. Developers could include less.js and write Less code directly, which would be converted to CSS on the fly. This client-side compilation wasn’t very performant for large projects, but it helped popularize the preprocessor concept.

Other preprocessors also emerged (Stylus in 2010, for example), but Sass and Less dominated. Each had its fans – Sass was powerful and had frameworks like Compass for added utilities; Less was simpler and was used in early versions of the popular Bootstrap framework. Twitter Bootstrap (2011) chose Less for its CSS source, demonstrating how preprocessors could streamline framework development and theming. By the early 2010s, many teams had adopted Sass or Less in their build workflows to manage their CSS for large applications.

Key advantages brought by preprocessors:

• Variables and Constants: Define a value (colors, spacing, font-sizes) once and reuse, which improves consistency across a site.

• Nesting and Scope: Write styles nested under their parent selectors, which mirrors HTML structure and avoids repetitive selectors – though over-nesting became a known pitfall (more on that later).

• Mixins and Functions: Package up reusable styles (like a button gradient or a clearfix) into a mixin, or use logic to generate repetitive CSS (loops, calculations for grid widths, etc.).

• Organized Files: Preprocessors allowed splitting CSS into multiple files and importing them, which vanilla CSS didn’t support at the time. This modularizes code by component or section.

All these features made CSS more maintainable as projects scaled. However, they also introduced a new compilation step and some complexity in the toolchain (Ruby or Node needed to compile Sass/Less to CSS). Still, by the early 2010s, preprocessors were a standard part of the front-end toolkit for many developers.

Organized CSS: BEM, OOCSS, and Friends (2010–2014)

Preprocessors helped with syntax, but they didn’t enforce how to structure your CSS overall. As teams collaborated on ever-larger stylesheets, they encountered familiar problems: overly specific selectors, style conflicts, and difficulty maintaining consistency. In response, the community developed CSS architecture methodologies – essentially guidelines or conventions to write cleaner, more modular CSS.

One of the earliest was Object-Oriented CSS (OOCSS), advocated by Nicole Sullivan around 2008–2009. OOCSS proposed treating CSS classes like “objects” – reusable chunks that are independent of context. For example, a generic .media class could define a block of media and text, and it could be reused in different places with minimal changes. Sullivan’s approach aimed to increase reuse and decrease redundancy: think of styling in terms of visual components (like modules) rather than individual pages. OOCSS planted the seeds for many techniques to come.

Around 2010, a team at Yandex in Russia introduced BEM (Block-Element-Modifier) methodology. BEM provided a structured, naming-convention-driven approach to CSS. In BEM, a “Block” is an independent component (like a navbar, card, or button), an “Element” is a part of that block (like an item in the navbar, or the title of the card), and a “Modifier” is a variant or state (like a large version of a button, or a highlighted card). These concepts are reflected in naming, e.g. card__title--highlighted might refer to a title element of a card block, in a highlighted state. BEM’s strict naming scheme (block__element--modifier) creates clarity about hierarchy and prevents clashing selectors by scoping names to a block. First introduced by Yandex in 2010​, BEM gained global popularity a few years later as developers saw its benefits for large projects. By encapsulating styles per component and avoiding generic class names, BEM made CSS more maintainable and scalable across big teams.

Another influential guide was SMACSS (Scalable and Modular Architecture for CSS), created by Jonathan Snook in 2011. SMACSS isn’t a library but a style guide taxonomy: it categorizes your CSS rules into five types – Base, Layout, Module, State, and Theme. For example, base styles are default element styles (e.g., h1, a), layout styles define major page regions, module styles are for reusable components, state styles are for dynamic states (like .is-hidden, .is-active), and theme styles handle alternate themes or skins. This categorization helps developers reason about their styles and where certain rules should live. Snook’s SMACSS (written in 2011​) was one of several attempts to bring more discipline to CSS in an era when projects were only getting larger.

These methodologies shared some common goals:

• Modularity: Treat CSS not as one big global sheet, but as pieces tied to components or purposes.

• Reusability: Encourage writing a style once (for a “component”) and reusing it, rather than rewriting similar styles in many places.

• Explicitness: Through naming conventions (like BEM’s long class names) or structured rules (SMACSS categories), make the intent of styles explicit. This helps new team members understand the code and prevents accidental style overrides.

• Team Collaboration: By having agreed-upon conventions, teams avoid stepping on each other’s toes in CSS. If everyone follows BEM, the chance of two developers creating conflicting class names is low. If following SMACSS, one knows where to add a new state style versus a base style.

Not every team formally adopted BEM or SMACSS, but the influence of these ideas is widespread. Even today, many CSS codebases use BEM naming or similar, and concepts like separating style concerns (structure vs skin vs state) are considered best practice. These methodologies were a direct response to “CSS sprawl” – without them, large CSS files can become brittle and hard to maintain. By the mid-2010s, using a CSS methodology was common on big projects, whether it was an official one like BEM/SMACSS or a team’s own conventions influenced by them.

The Component Era: Frameworks Change How We Style (2015+)

Around the same time that CSS architects were wrangling stylesheets, a broader revolution was happening in front-end development: the rise of JavaScript frameworks and component-based architecture. AngularJS (by Google) gained popularity circa 2010, React (by Facebook) launched in 2013, and Vue.js in 2014. These frameworks encouraged developers to build UIs as collections of components – self-contained pieces of UI that manage their own logic and (often) their own styling. This shift had a profound impact on styling practices.

In traditional multi-page websites, you might have one large CSS file (or a few) loaded across all pages. But in a single-page application (SPA) with components, it made sense for each component to carry some styles with it, to avoid interference with others. Frameworks began offering solutions for encapsulating styles at the component level:

• Angular (2+): Angular (from version 2 in 2016 onward) introduced the concept of component-scoped styles. By default, Angular components use View Encapsulation, which in practice means the styles you write for a component are applied to that component’s template and do not leak out. Under the hood, Angular can emulate this by adding unique attributes to elements and matching those in CSS, or use Shadow DOM when available. The result is that with Angular 2+, “component styles are protected and won’t bleed into other components by default.”​ This was a game-changer: you could write simple CSS selectors in a component’s stylesheet (.css or .scss file) without fear that they would accidentally target the wrong element elsewhere in the app – something not possible with plain global CSS unless you were very careful with naming. Angular’s approach brought the benefit of BEM (encapsulation) without the need to manually name-space everything – the framework did it for you.

• React: React took a more library-like approach – it didn’t dictate styles, but its philosophy of building UIs encouraged new styling solutions. Early React apps often still used global CSS or CSS modules, but many React developers sought to co-locate styles with components. One approach was CSS Modules (first popularized around 2015), which let you write CSS in a file and import it into your component; the build tool ensures that class names are locally scoped (e.g., .button in ComponentA.css gets transformed into a unique .ComponentA_button__abc123 in the final CSS). This gives isolation similar to Angular’s, but via a build step. Another approach, which really took off in the React community, was writing styles in JavaScript, aka CSS-in-JS (next section will dive into this). React’s flexibility spawned a plethora of styling strategies, but the key trend was encapsulation – whether via modules, in-JS, or BEM conventions, React apps typically avoid global CSS leakage by scoping styles per component.

• Vue.js: Vue single-file components (SFCs) encapsulate HTML, JS, and CSS in one .vue file. Vue allows a <style scoped> tag which, like Angular, automatically scopes the CSS to that component only. This provides convenience similar to Angular’s approach. Vue developers can also choose to use global CSS or module systems, but the single-file component format encourages keeping the CSS close to the markup it styles.

• Web Components: In parallel to framework-specific solutions, the web platform itself introduced Web Components, which include the Shadow DOM for native style encapsulation. Web Components became a W3C standard in 2019 (with roots in earlier specs), and allow developers to create custom elements with truly isolated styles (the Shadow DOM ensures styles defined in a shadow root don’t affect the outside, and vice versa). While Web Components aren’t as widely used as React/Angular/Vue, they influenced the idea that styling can be bundled with components.

Overall, by the late 2010s, the paradigm had shifted: thinking in terms of components (and their styles) rather than pages. This meant a few things for styling:

• Developers began splitting CSS by component, either manually (one file per component) or by using the framework’s mechanism (CSS Modules, SFCs, etc.). The days of one gigantic .css file with thousands of lines for the whole site were fading.

• Global styles were still used (for base styles, common typography, theme colors), but most new development happened in a component scope. This reduced the risk of unintended side effects – a core principle from the earlier methodologies taken to the next level.

• Because components could be assembled like lego blocks, a design system mindset emerged: teams created sets of standardized components (buttons, cards, modals, etc.) each with their own styles, ensuring consistency across the application.

By embracing components, frameworks also set the stage for new ways to author CSS that fit better in a JavaScript-heavy workflow – most notably, the rise of CSS-in-JS.

The Rise of CSS-in-JS (Late 2010s)

As React and other component frameworks rose in popularity, developers looked for ways to simplify styling in these environments. Enter CSS-in-JS, a paradigm where CSS is written in JavaScript (or TypeScript) instead of in .css files. This approach initially sounded heretical to some – after all, separating CSS from JS had been a longstanding best practice. But CSS-in-JS came with compelling advantages for component-based systems, and it quickly gained a following.

One of the breakthrough libraries was styled-components, released in 2016. This library (along with others like Emotion, JSS, and Radium in that era) enabled developers to define styled React components using JavaScript template literals that contained CSS syntax. For example, you could write:

import styled from 'styled-components';
const Button = styled.button` background: ${props => props.primary ? "blue" : "gray"};
color: white; padding: 10px; `;

This defines a Button component with styles that change based on props (here, if primary prop is true, use blue background). Styled-components would then ensure those styles are applied and scoped only to that component. The popularity of this approach exploded – by the end of 2016, styled-components “took the React world by storm,” and in the following years many React apps adopted CSS-in-JS libraries. According to the State of JS survey, by 2021 over half of surveyed developers had used styled-components​, a testament to how mainstream this approach became in the React ecosystem.

Why CSS-in-JS? Several reasons drove its adoption:

• Co-location: Write styles in the same file as your component logic. This makes it easy to keep a component’s implementation self-contained. No need to switch between JS and CSS files – one less context switch for developers.

• Dynamic styling: Because it’s JavaScript, you can use all the power of JS to compute styles. The example above shows prop-based styles; you can also do themes via React Context, calculate widths, use loops, etc. Without a preprocessor, CSS can’t easily do logic based on runtime data – CSS-in-JS can.

• Avoiding specificity issues: CSS-in-JS often generates unique class names (much like CSS Modules) for each styled component, so you don’t worry about one component’s styles interfering with another’s. This is very appealing in large apps – it’s essentially an automatic BEM-like scoping without you needing to manually write BEM classes.

• Better developer experience: Many CSS-in-JS libraries provide features like automatic vendor prefixing (so you don’t need something like Autoprefixer), and some ensure that only the styles for rendered components are injected on the page (critical CSS). This can optimize performance and avoid loading unused styles.

Of course, CSS-in-JS has its tradeoffs. A common criticism is performance: injecting styles via JavaScript can be slower than having all styles in a static CSS file, especially if done at runtime. Early CSS-in-JS libraries would insert <style> tags dynamically and often recalc styles on the fly, which for very large apps could cause noticeable jank. There’s also the concern of bundle size – adding a JS library to handle styling comes at a cost. Over time, many CSS-in-JS solutions addressed these issues by using compile-time extraction (turning the styles into static CSS during the build, as in newer libraries like Linaria or compiled CSS-in-JS frameworks) or other optimizations.

Nonetheless, by the late 2010s, CSS-in-JS was a major trend. It fit particularly well with React’s component structure (and similarly in Vue or Svelte, though less dominant there). It also sparked debates in the community – some developers loved the convenience, while others felt it was an overreach, complicating CSS which is a fundamentally simple, declarative language. We even started to see some “backlash” by the early 2020s, where certain teams that had gone all-in on CSS-in-JS decided to revert to simpler approaches for performance or simplicity​. This highlights an important lesson: no approach is one-size-fits-all, and what’s fashionable in one era might be re-evaluated in the next. We’ll discuss how to choose among these approaches later on.

Before that, there was another orthogonal trend happening in CSS around the same time – a shift toward utility-first CSS, which took a very different philosophy than component-specific styles or CSS-in-JS.

Utility-First CSS and Atomic Design (Late 2010s)

While many developers were co-locating styles with components or using methodologies to carefully structure CSS, another school of thought was emerging: What if we don’t write custom CSS for each component at all? Instead, what if we had a predefined set of tiny utility classes for common styles (like .mt-4 for margin-top or .text-center for centering text) and we build our UI by composing these in our HTML? This idea isn’t entirely new – it traces back to concepts like Atomic CSS or functional CSS from the mid-2010s – but it really took off with modern tooling in the late 2010s.

A pivotal project in this space is Tailwind CSS, a utility-first framework first released in late 2017​. Tailwind provides a comprehensive set of small classes that each apply a single CSS declaration (or a small group). For example, Tailwind’s .bg-blue-500 sets a background color, .px-4 adds horizontal padding, .flex makes an element a flex container, etc. Instead of writing a new CSS class for your “Card” component, a developer using Tailwind might write <div class="bg-white text-gray-800 p-6 rounded shadow-md"> directly in their HTML/JSX – applying a bunch of utility classes to get the desired appearance.

Why do this? The utility-first approach offers several benefits:

• Speed of Development: You don’t have to name or define new CSS classes for every element. You pick from a palette of existing utilities to style something on the fly. This can be very fast once you’re familiar with the classes. It also avoids the mental overhead of context-switching between HTML and CSS files; you style as you build the markup.

• Consistency: Because the utility classes are pre-defined (often based on a design system scale for colors, spacing, etc.), using them promotes consistency. If every margin is one of a set of values (e.g., 0.5rem, 1rem, 2rem, etc. via classes) and every color is from a standardized palette, your UI is less likely to have arbitrary, inconsistent values.

• Small CSS Bundle (with Purging): Utility frameworks like Tailwind can generate thousands of classes, but modern build tools can “purge” (tree-shake) the ones you don’t use. The result is your production CSS contains only the classes actually used in your HTML. This can be surprisingly efficient – many Tailwind projects end up with smaller CSS files than an equivalent hand-written stylesheet that might include unused styles or overlapping rules.

• Design Systems and Teams: Utility classes can serve as the primitive building blocks for a design system. Designers can work with developers to decide on the scale of spacing, colors, etc., and those become the utility classes. Team members then have a common language: a developer sees class="text-lg font-semibold text-blue-600" and can immediately understand the visual outcome without hunting through CSS files.

However, utility-first CSS also has its downsides and critics. The most common critique is that it bloats HTML and mixes concerns: the HTML structure is littered with what essentially are styling instructions. Detractors argue this is similar to inline styles or the old presentational markup days. As one developer questioned, “The entire point of CSS is to separate style from structure. How does applying composable utility classes to all of your HTML elements differ from the old days of using HTML attributes for styling?”​

This captures the initial skepticism many had – are we undoing the separation of concerns that CSS was meant to achieve?

Proponents of utility-first respond that these classes are an abstraction of CSS, not a return to <font> tags. They point out that utility classes are still defined in CSS – the style rules are just applied via reusable classes rather than unique selectors. Also, since the classes are thoughtfully chosen and systematized, the approach remains maintainable. In fact, many who actually try utility-first styling report a boost in productivity. As one Tailwind user noted, once you learn the syntax, “it gets to be VERY productive… like writing CSS at a slightly higher level of abstraction,” largely because you “don’t have to edit two separate files” (HTML and CSS) for styling​. The ability to rapidly prototype designs by composing utilities can be empowering.

The utility-first vs. custom CSS debate often comes down to preference and context. Some teams love that their markup is self-descriptive (you can often guess the look from the class names) and that they rarely write CSS from scratch. Others prefer the semantic clarity of naming a class for what the component is (e.g., .card or .navbar) rather than what it looks like. One compromise is to use utilities for spacing and small tweaks but still have semantic component classes for higher-level styling. Tailwind even allows extracting components (using @apply or just creating new classes that compose utilities) when needed, so it’s not an all-or-nothing proposition.

By the early 2020s, Tailwind CSS skyrocketed in popularity, joining the likes of Bootstrap and Foundation as one of the go-to CSS frameworks, but with a very different philosophy from those older UI component frameworks. Utility-first CSS became a mainstream option, especially in new projects and startups that valued speed. It’s worth noting that even some teams that previously went all-in on CSS-in-JS shifted to a hybrid approach: using a utility class system alongside simpler CSS modules, to get the best of both worlds (fast development, good runtime performance)​.

Modern Best Practices, Pitfalls, and Anti-Patterns

With so many approaches in play – from BEM to Tailwind, Sass to styled-components – the state of front-end styling in 2025 is incredibly rich. Yet, regardless of approach, there are common pitfalls and anti-patterns that engineers should watch out for. Many lessons have been learned over the past two decades of CSS evolution:

1. Global Scope & Specificity Wars: One classic CSS pitfall is relying on overly broad or overly specific selectors in the global scope. For example, using an #id selector or a long chain like #main .content .profile .details p will make it hard to override styles later. Overly specific selectors lead to what’s known as specificity wars – you end up needing !important or even more specific rules to counteract earlier styles. A notorious anti-pattern is liberally using !important to force styles; this often cascades into a mess where “the only way to override a style is by using another !important, leading to a messy, hard-to-manage stylesheet.”​ Modern methodology (BEM, etc.) and encapsulation are partial solutions: they encourage focusing on classes with moderate specificity and avoid ids or element selectors for styling. To avoid this pitfall: keep selectors as simple as needed, prefer classes over ids, and use the cascade intentionally (or not at all, if you encapsulate).

2. Over-Nesting in Preprocessors: Sass and Less made nesting selectors convenient – perhaps too convenient. It’s easy to create deeply nested rules mirroring HTML structure, but this often yields very specific CSS and large selectors that are hard to maintain. For instance, nesting five levels deep in Sass will generate a selector like .nav ul li a span { ... }, which is brittle. This is such a common mistake that it’s explicitly called out as an anti-pattern​. The fix is straightforward: limit nesting, ideally no more than 2 levels deep in most cases. If you find yourself writing Sass with heavy indentation, consider refactoring using BEM (so you can flatten the structure).

3. Inline Styles and DOM Manipulation of Styles: In modern frameworks, we rarely see <div style="..."> in markup for primary styling, because it mixes content and style. This is considered an anti-pattern except for dynamic or one-off cases. The same goes for using JavaScript to set CSS properties on elements one by one – it’s usually better to toggle classes (perhaps via a framework) and have those classes defined in CSS. Inline styles also don’t take advantage of CSS cascade or media queries easily, and can’t be reused. An excessive use of inline styles is highlighted as a “how not to do CSS” mistake​.

4. Not Leveraging Modern Layouts: A historical pitfall was sticking to outdated techniques like floats for layout well past their prime. As of 2025, CSS Grid and Flexbox are well-supported and vastly simplify layout compared to float/clear hacks or early frameworks. Using floats for whole-page layout today is an anti-pattern – it results in more markup (clearing elements, etc.) and fragile design. If you catch yourself adding a clearfix, ask if a flexbox or grid could achieve the layout more cleanly. Modern CSS capabilities (flex, grid, multi-column, container queries) exist to make these older approaches obsolete. As a solution, continuously update your CSS knowledge to avoid clinging to workarounds that CSS no longer needs.

5. Over-Reliance on Frameworks Without Understanding: Whether it’s Bootstrap, Tailwind, or Material UI, using a framework blindly can lead to problems. Common issues include overriding a framework’s styles in many places (if you find yourself writing a lot of !important to override Bootstrap, you might be fighting the framework too much), or not customizing it (leading to a “Bootstrap look” that doesn’t match your brand). It’s an anti-pattern if your team cannot debug CSS issues because they originate in a black-box framework. The remedy is to treat frameworks as helpers, not crutches: read their docs, use their patterns, but also know CSS fundamentals to extend or override properly when needed. Also, purge or remove unused parts of frameworks in production to avoid bloat.

6. Ignoring Performance of Styles: We think of performance mostly in terms of JavaScript, but CSS can impact it too. Huge CSS files (500KB+ of CSS) can slow initial page rendering, and heavy use of complex selectors (e.g., universal selectors or very nested ones) can marginally affect style calculation. More critically, some CSS-in-JS (if not optimized) can delay styles from applying, causing flashes of unstyled content. And large numbers of DOM elements with individual style tags (in extreme CSS-in-JS cases or poorly managed Shadow DOM) can tax the browser. The pitfall is not considering these aspects. The guidance: measure and optimize CSS delivery – e.g., use critical CSS, code-split your styles if using a SPA, and prefer simpler selectors. If you use CSS-in-JS, consider libraries that compile to static CSS or use it sparingly for dynamic parts.

7. Lack of Naming Conventions or Consistency: This is more subjective, but a codebase where one developer uses .red-btn class, another uses .button-primary, and another uses #submit for the same kind of element is clearly unmaintainable. Having no agreed-upon approach is an anti-pattern in itself. It leads to duplicate styles, dead code, and confusion. The fix is choosing some methodology (even a lightweight one): maybe it’s BEM, maybe it’s “component-name__element” convention, or maybe it’s simply “all classes must be lowercase and use dashes and reflect purpose.” Consistency is key. Modern tooling can help enforce this (style linters, etc.), but it largely comes down to team agreement.

8. Over-engineering or Under-engineering Styles: We’ve seen both ends. Over-engineering: creating a complex build with five different preprocessors and frameworks when a simple CSS file would do, or abstracting every little style into CSS variables and mixins even when not truly needed – this can make simple things hard to follow. Under-engineering: dumping thousands of lines in one file with no structure at all. The sweet spot is pragmatism. Use methodologies and tools that provide clear value (e.g., a design system, a good naming scheme), but don’t introduce complexity for its own sake. For instance, if you have a small site, you probably don’t need CSS-in-JS or a utility framework – plain well-structured CSS might be fine. Conversely, if you have a large application with multiple themes, using CSS variables and a methodology is almost a must.

Being aware of these pitfalls will help you avoid common mistakes, regardless of which styling approach or framework you use. The good news is that the community has already identified many of these, and both practices and tools have evolved to mitigate them (for example, CSS cascade layers introduced in 2022 can help manage specificity across large projects; autoprefixer tools handle vendor issues; linters can catch things like !important usage, etc.). As you build, keep these lessons in mind and you’ll sidestep a lot of technical debt in your CSS.

Choosing the Right Styling Approach for a Project

Given the rich history and myriad options, how should an engineer in 2025 decide on a styling approach for a new project (or a major revamp)? The truth is, there is no one-size-fits-all answer – it depends on your team, project requirements, and even personal or organizational preferences. Here are some practical insights and considerations to help guide the decision:

1. Team Expertise and Preference: Assess what your team is familiar with. If you have CSS veterans who have long used Sass + BEM, that combo might be very productive for you – there’s little learning curve and many gotchas are already known. On the other hand, if your team is full of React developers who think in JavaScript, CSS-in-JS or styled-components might click more naturally for them. A solution that the team knows (or is eager to learn) will likely be executed better than something foreign, even if the foreign option is trendy. Leverage your team’s strengths.

2. Project Size and Longevity: The larger and longer-lived a project is, the more you benefit from formal structure. For a small marketing website or a quick prototype, you might not need a heavy architecture – a few well-organized CSS files or a utility framework to move fast could be fine. But for a big application that will be maintained over years, investing in a scalable methodology (BEM/SMACSS or a design system with utilities) pays off. For long-term projects, also consider maintainability: Will new team members understand the approach? Is there documentation (internal or community) to help them get up to speed? Established methodologies have the advantage here.

3. Design Consistency vs. Flexibility: If your project has a strong design system or needs pixel-perfect consistency, you may lean towards approaches that enforce consistency. Utility-first frameworks shine here because they literally encode the design system into class names – deviating requires effort. Likewise, a component library (like using Material UI or Ant Design) provides consistency out-of-the-box. On the other hand, if your project is more free-form or creative, and you expect unique styles and custom layouts, a utility framework might feel too constraining and verbose. You might prefer writing bespoke CSS for each component (perhaps with BEM and Sass to assist). Consider how much of the UI can be standardized. Many projects benefit from a hybrid: standardize the basics (colors, spacing, common components) and allow custom styling for unique features.

4. Development Speed Needs: Sometimes you need to crank out a UI quickly – startup culture and MVPs value this. Utility-first can be very fast once you know it, as can using a ready-made CSS framework (like Bootstrap’s components). If time-to-market is critical, choose something enabling rapid development (Tailwind, Bootstrap, or even plain CSS with quick-and-dirty classes). Conversely, if you have time to engineer carefully or the project demands very clean separation (e.g., in a large enterprise with strict code standards), you might favor a more structured approach even if initial development is slower.

5. Framework Integration: The choice might be influenced by the primary JavaScript framework you use. For example, if you’re deep in the React ecosystem, CSS-in-JS libraries or CSS Modules will integrate seamlessly, and there’s plenty of community support for them. If you’re using Angular, the framework already gives you style encapsulation – so you might just use simple Sass files per component and call it a day (Angular also has good support for Tailwind or global styles, but many Angular devs find less need for CSS-in-JS). Vue offers scoped styles in SFCs, which might reduce the need for something like styled-components (though you can still use them if desired). In short, align with your tech stack: each framework has known best practices for styling; it’s wise to at least consider those conventions unless you have strong reasons not to.

6. Performance Considerations: If your application is performance-sensitive (e.g., a complex web app that needs to run on low-end devices, or an app where initial load time is critical), be mindful of the styling approach’s impact. Traditional external CSS files are very performant once loaded (CSS is parsed once, and applying classes is cheap). Approaches that generate styles at runtime or inject lots of style tags (some older CSS-in-JS, heavy Shadow DOM usage) might incur a cost. This doesn’t mean avoid them at all costs – just be sure to measure and, if needed, use modern variants that mitigate issues (like using CSS-in-JS libraries that compile to CSS, or splitting your styles). If you anticipate thousands of components on screen (like a data grid or big dashboard), a utility-first approach might actually be beneficial to avoid a huge stylesheet, or a well-structured BEM CSS might be easier to debug – weigh these factors with performance in mind.

7. Tooling and Workflow: Another practical factor is your build process and tools. If your project is set up with Webpack/Vite etc., adding Sass is trivial – so using a preprocessor is a non-issue. But if you’re working in a more barebones environment or something like a CMS with limited build steps, maybe adding a build step for Sass is not worth it and plain CSS or a simple PostCSS pipeline is better. If you use TypeScript heavily, you might appreciate typed CSS Modules (there are libraries that generate .d.ts for CSS classes), which nudge you to use CSS Modules approach. Or if you love using design tokens (perhaps coming from a design tools integration), using CSS variables in plain CSS might suffice. Essentially: consider what your existing toolchain supports readily and what fits naturally.

8. Community and Future-Proofing: It can be risky to adopt a very niche styling approach that few others use, as you might struggle to find help or hiring people experienced in it. Approaches like BEM, Sass, CSS-in-JS, Tailwind – these are widespread enough that you’ll find plenty of resources and contributors who know them. But a very custom in-house methodology or an obscure library could pose challenges. Also, consider the longevity: CSS itself is not going anywhere, but specific libraries can rise and fall. (For instance, if you were betting on Stylus preprocessor, note that it’s far less used now than Sass/Less). If you choose a newer approach, have a fallback plan or ensure the CSS it produces is clean so you could maintain it even if the tool is gone. On the flip side, don’t be afraid to try modern techniques that solve real problems – just be conscious of their maturity.

Finally, remember that you can mix and match approaches to some extent. Many large applications use a combination: perhaps legacy pages still use BEM CSS, new components use CSS-in-JS, and utility classes are used for spacing and layout helpers. It’s okay to not be purist. The key is managing this complexity – for example, you might enforce that new code should follow the new approach, and gradually refactor old code. Just avoid mixing in the same component or context unless you know what you’re doing (it can be confusing if some styles come from global CSS and some from CSS-in-JS for the same element).

In summary, choosing the best styling approach is about finding the right balance for your situation. Use the historical context and lessons to inform your choice: for instance, if you know your team struggled with specificity issues in the past, maybe a utility-first or CSS-in-JS approach that limits cascade could help. If you experienced a messy global CSS file, maybe adopting BEM with a build process will instill order. And if you’ve felt slowed down by too much ceremony in CSS, a lightweight approach with just Tailwind or just raw CSS might speed you up. Weigh the pros and cons in light of your project’s needs.

Looking Forward: Beyond 2025

Front-end styling has come a long way in 30 years, but the evolution is not done. What might the future hold for CSS and styling techniques beyond 2025? While it’s hard to predict precisely, a few trends and emerging technologies hint at where we might be heading:

• Native CSS Enhancements: The CSS standards continue to grow more powerful, potentially reducing the need for external tooling. Features like CSS Cascade Layers (2021) help developers manage specificity in large projects by creating explicit style layers (e.g., one for base styles, one for components, one for overrides) – this is like an answer to the specificity wars at the language level. Container Queries (2022) allow components to style themselves based on their container size, not just the viewport, which could reduce the need for some JavaScript layout hacks or complex responsive logic. There’s also talk of a future **:has() selector (now available in some browsers) enabling parent-selectors which could simplify certain patterns. As these features become widely supported, some tasks we used frameworks or scripts for might be achievable with pure CSS. For example, a lot of “responsive component” patterns that resorted to JS could be done with container queries + Flexbox/Grid alone. We might see developers relying more on raw CSS capabilities and simplifying their toolchains when possible.

• Design Systems & Tokens: The industry trend toward design systems means more standardization in how styles are defined and shared. Technologies around design tokens (platform-agnostic variables for colors, spacing, etc.) are evolving. It’s possible that standards will emerge to make using design tokens in CSS easier (some of this can be done with CSS custom properties today). We may see more integration between design tools (like Figma, Sketch) and code – for instance, design tokens exported directly to CSS or JS, closing the gap between design and development. As more companies adopt design systems, the styling approach often becomes a part of that system (whether it’s a custom CSS framework or guidelines on using Tailwind or a component library). This could lead to more consistency across the industry, where certain patterns become defaults.

• Continued Refinement of CSS-in-JS and Alternatives: CSS-in-JS is not static; it has been undergoing its own evolution. The newer generation of CSS-in-JS libraries performs compilation at build time (no runtime injection) and smartly output static CSS files. This approach gives many benefits of CSS-in-JS (scoping, using JS logic for styles) without the performance cost. We might see these compile-time CSS-in-JS tools become the norm, or even get absorbed into framework tooling. For example, frameworks could natively support something like “scoped CSS with JS expressions” that compiles away. On the other hand, the boundaries between “just CSS” and “CSS-in-JS” might blur: with proposals like the CSS @when rule (conditional rules in CSS) or more powerful native capabilities, developers might not need JavaScript to achieve dynamic styling. In React, there’s talk about evolving the styling story (perhaps a future React CSS runtime or better SSR integration). By 2030, it wouldn’t be surprising if the concept of CSS-in-JS either becomes so standard that it’s just a checkbox in your framework, or it gets replaced by something new that addresses its shortcomings while preserving its strengths.

• Web Components & Interoperability: If Web Components gain more traction, styling might standardize around them for certain use cases. The Shadow DOM gives a built-in way to avoid style leakage, which was one big reason for many methodologies. As developers get more comfortable with Shadow DOM (even when using frameworks – e.g., Angular can use native Shadow DOM, Lightning Web Components in Salesforce use it, etc.), we may see styling strategies that leverage this. Perhaps design systems will ship as Web Components with encapsulated styles, so you just use the component and don’t worry about CSS conflicts at all. This could complement frameworks, providing standard base components that work anywhere.

• Tooling and AI: On the tooling front, we might see smarter CSS linters and refactoring tools that can manage large codebases, or even AI-assisted styling. Imagine an AI that can analyze your CSS and suggest a refactor to BEM, or identify all those unused styles (some tools do this statically, but AI could be more context aware). AI might also help bridge design and code – e.g., generating CSS from design mockups with better accuracy, or suggesting class name conventions based on project context. It’s speculative, but given the rise of AI in coding assistance, CSS could benefit too (perhaps by suggesting tailwind class combinations or writing media queries for you).

• Performance and Platform Changes: As devices evolve (AR/VR, foldable screens, etc.), CSS will adapt. Responsive design might need to consider new dimensions. Also, with increasing emphasis on performance and Core Web Vitals, there’s a push to ensure styles (like any resource) are delivered optimally. Techniques like extracting critical CSS might become default in frameworks. There’s already a move in React frameworks (Next.js, Remix) to do style splitting automatically. By 2025 and beyond, more of these optimizations could be baked in, so developers focus on writing styles and the tools ensure they load efficiently.

In essence, the future will likely bring more convergence in some areas (perhaps a set of best practices that most projects follow, much like how component-based UI is now standard) and more innovation in others (new CSS features, new libraries). As an engineer, staying informed and adaptable is key. What remains constant is the core goal: making it easier to style applications in a maintainable, efficient way. The specifics of how will continue to evolve.

Now you know

Front-end styling has journeyed from humble beginnings – tweaking fonts on static pages – to a sophisticated discipline with multiple paradigms. We’ve seen how early hacks gave way to CSS, how the community tamed the cascade with methodologies, and how the component revolution upended our approach to organizing CSS. Today, engineers have more choices than ever: whether to write styles in a CSS file or in JavaScript, whether to adopt a utility-first library or craft a bespoke design system, whether to lean on classic Sass or modern CSS variables.

Understanding this history isn’t just an academic exercise; it’s practical knowledge. It reveals why certain best practices exist – why we avoid IDs in CSS (a lesson from specificity fights), or why BEM came about (to enable large teams to collaborate without collision), or why Tailwind’s approach resonated (speed and consistency). With this context, you can make more informed decisions. Perhaps you’ll realize your small project doesn’t need the heavyweight approach you were considering, or conversely, that your growing app would benefit from a methodology you hadn’t tried. You might combine ideas – using BEM naming within a CSS-in-JS setup, for example – to get the best of both.

Crucially, there’s no silver bullet. Every approach has pros and cons, and what works for one project/team might not for another. What the evolution teaches us is to be intentional: choose a strategy that addresses the challenges you anticipate, and be ready to adapt as needs change. And don’t be afraid to evolve your styling approach over time, just as the industry has. Legacy code can be refactored (gradually) toward better patterns, and new features can pilot new techniques.

In a field that changes as quickly as front-end development, having this historical perspective is like having a map. It won’t tell you exactly where to go, but it shows you the terrain and the paths others have taken – including where they stumbled. As we step beyond 2025, new tools and techniques will emerge, but they’ll build on the foundations we’ve discussed. By keeping these lessons in mind, you as an engineer can confidently navigate the future of CSS, crafting UIs that are not only beautiful and responsive but also maintainable and efficient.

And yet… we can’t simply ask an LLM, “Create a PR with a new login endpoint for my enterprise codebase,” and watch it handle everything automatically - at least not in any general, reliable way. Why? Because for serious, real-world development, context is everything. Production environments are full of intricate domain logic, legacy architecture quirks, and business-specific constraints that a model just can’t absorb with a single prompt.

A few AI-driven products have made headlines by claiming major revenue or funding: Cursor hitting impressive ARR, Bolt.new raising nine-figure rounds, or Vercel V0 launching with big hype. These tools do create meaningful value, but they’re still fundamentally constrained by how they handle context. To me, that’s the real story: an ongoing search for how best to feed large, complex codebases into AI while preserving nuance. Until then, these are better fitting for spinning up weekend side projects than for building features at 100+ engineer companies.

^ Primagen showcasing the woeful current practical state of Devin. The Devin-dream is interesting, but the current real-world value appears weak.

Three Patterns of AI Code Generation

I’ve been observing three distinct approaches in the market. Each wrestles with the context problem in its own way.

1. “New Project” Generators (Bolt.new, Lovable, V0, etc.)

One category is focused on spinning up new codebases from scratch. You provide a prompt like, “Build me a minimal Rails app with user registration,” and - boom - a service stitches together a few templated modules, dropping in some boilerplate code to get you started.

Strengths:

• By only dealing with greenfield scenarios, these tools dodge the complexities of preexisting architecture. No legacy schemas or cryptic internal APIs.

• It’s like the AI version of create-react-app: quick, practical, and surprisingly helpful if your aim is a demo or weekend project.

Limitations:

• For any medium-to-large organization, the real challenge isn’t spinning up something brand new; it’s integrating new features into an existing labyrinth of code.

• Even in modest codebases, they can’t parse years of domain-specific logic or data schemas. That remains a manual task - one that grows exponentially with project size.

2. IDE-Based Assistants (Cursor, Copilot, Windsurf, etc.)

The second category fits neatly into a developer’s daily workflow. You’ve likely seen tools like GitHub Copilot: they integrate directly into your IDE and generate code suggestions as you type.

Strengths:

• They work well in complex codebases because the human developer guides the AI by opening relevant files, highlighting specific contexts, and verifying suggestions.

• This has proven to be the most successful short-term strategy for enterprise use. Engineers already live in their IDEs, so it’s an easy add-on with tangible benefits.

Limitations:

• Although these tools are genuinely helpful, they still rely on the human to supply context incrementally. It’s not a “fire-and-forget” solution.

• You’re not asking the AI to read the entire codebase at once. You open a handful of files, the AI sees them, and that’s it. For big, cross-cutting features, you end up doing a lot of manual bridging.

3. “Headless Agent” Solutions (Devin, Factory, etc.)

The third approach is more ambitious: these tools aim to operate in the background, ingesting your entire repo and waiting for tasks. For instance, you create a GitHub issue or a Linear ticket, the AI sees it, tries to figure out the relevant code, and then automatically opens a PR with a fix or new feature.

Strengths:

• This is the ultimate vision of code generation: ask for a high-level outcome (“add a new authentication method”), and the system scours the repo, hunts down relevant sections, and implements changes.

• Could save developers from drudgery and context-switching if it worked perfectly.

Limitations:

• The context gap is still huge. For large codebases, it’s nearly impossible to incorporate all relevant details without constant back-and-forth guidance.

• Right now, these tools reliably handle only small bug fixes or housekeeping tasks. For anything bigger, they tend to produce broken or incomplete solutions.

Where Do We Go From Here?

A lot of people are betting that models will get orders of magnitude smarter, cheaper, and more context-aware over the next 12 to 24 months. I’m generally in that camp - I do think we’ll see exponential improvements in areas like context window size and inference speed.

In that world, you might imagine entire codebases being shoved into a single context window, letting the AI reason about thousands of files at once. That brute-force approach could eventually erode the need for an IDE-based pattern, because the AI would “just know” everything about your project after one big prompt. Sam Altman has openly hinted that the complicated retrieval-augmented generation (RAG) we use today might end up a footnote, superseded by bigger, cheaper models that can ingest everything at once.

But I’m cautious for three reasons:

1. Learning On the Fly: Human brains train and infer simultaneously. Today’s AI models are not good at actively re-training when they encounter new domain concepts. They infer from a static knowledge state. Maybe Google’s new Titan transformers will help?

2. Context Windows Are Finite: Even a “two-million-token” model is dwarfed by the kind of data a developer might hold in their head or the version control history that spans years and millions of lines.

3. Signal vs. Noise: Dumping an entire codebase into a model’s prompt can drown the signal in a sea of irrelevant details. Performance often degrades when the input is cluttered.

A Practical Approach for Today

Given these constraints, if I were to build an AI code-generation product right now (targeted at large, real-world codebases), I’d lean on a few design choices:

Background Analysis

• Set up a process that regularly scans the codebase, file by file, building a robust index of references and dependencies. It can do this asynchronously, so users aren’t waiting around.

• Over time, accumulate a detailed “map” of the code’s structure, pulling in only the most relevant context for each potential fix.

Small, High-Confidence Fixes

• Focus on specific, repeated patterns - like deprecation warnings, unsafe patterns, or functions that are obviously inefficient.

• When the system is sure it has a valid fix or optimization, it opens a small PR. If it’s not sure, it does nothing. This avoids spamming developers with half-baked ideas.

Limit the Scope

• Don’t attempt net-new features or major refactors unless the confidence is rock-solid. For those tasks, an IDE-based approach or a human-led design cycle is still safer.

• Accept that some big changes are simply out of scope, at least until the model (and context windows) get significantly more advanced.

Learn from PR Interactions

• Treat every acceptance or rejection of an AI-generated PR as a data point. Slowly, the system can refine its sense of what “good” or “acceptable” changes look like in your specific codebase.

Incremental Upgrade Path

• When bigger, better models become available, swap them in under the hood. If eventually the model can handle broader changes, that’s great - but you don’t have to overhaul the user experience.

• The key is to keep building user trust along the way. A developer who sees five high-quality fixes is more likely to trust the sixth, even if it’s bigger.

Right now, the sweet spot for code generation in large, messy codebases is the IDE-based pattern. It’s the easiest for real teams to adopt, and it has a track record of success because humans remain in the loop. But it’s also likely to be a transitional stage. If context windows and model intelligence progress as fast as people expect, the notion of pointing and steering an AI line by line may fade. We’ll just trust the AI as if it were a well-informed teammate.

Yet I’m not convinced we’ll see “ask for a new feature in Slack, get a perfect PR” across a multi-million-line codebase next week or even next quarter. There’s a gap between today’s demos and a truly robust solution for large-scale production systems. That’s why I believe a more methodical, iterative approach - focusing on small, high-value fixes first - might actually yield the most tangible short-term impact.

That grind has forced me to reflect on what works and doesn’t in the recruiting process—and I want to share some of those reflections. They’re cobbled together from long conversations with other engineering leaders, talent leads, and a ton of personal experimentation.

What Interviews to Run (They’re All Imperfect)

The first realization I’ve come to is that the specific interviews you run don’t matter too much. You’ll find entire threads of angry diatribes online about why “this” or “that” kind of interview sucks. At some point, you just have to pick a poison and calibrate consistently on it. The industry is famously fractured on how to assess technical skill; if there were a perfect solution, we’d have settled on it by now.

I’ve tried all variations at Graphite. My main takeaway is that algo-style coding interviews, while imperfect, have been the most consistently useful. Take-homes demand a ton of candidate time, are often cheatable (especially with AI), and produce results whose quality can vary widely based on how much effort someone invests. Did a candidate submit an amazing project because they spent 20 hours on it or because they’re exceptionally talented? Hard to say. On the other hand, here’s where algo-style interviews deliver:

1. They’re tried and tested. There’s a well-established format that’s understood across our industry.

2. They’re easily preparable (and beatable). Both new grads and seasoned engineers can practice and feel some level of control over their fate. It’s a more level playing field.

3. They can fit into 45 minutes. You get a tight, controlled environment to glean nuanced signal.

4. They have a correct answer. That reduces variance and personal bias when deciding pass/fail.

At Graphite, we often run two separate algo interviews, each with a different interviewer. That helps mitigate random flukes: even if someone completely chokes on a question in one interview, they still have a second shot. Interestingly, I don’t see huge divergence in how candidates perform across those two interviews—but it’s a good safety net. In the future, I aspire to experiment more with 45-minute-long practical-style interviews.

Beyond those, I typically run:

• A systems architecture whiteboarding interview

• An experience interview

• An interview led by cross-functional stakeholders (e.g., Product or Design)

I Love the Architecture Interview

I find the architecture interview provides most of the deeper signal I need. It tests fluency, reasoning, and open-ended technical thinking. A great candidate might discuss tradeoffs between REST, GraphQL, gRPC, or event-driven APIs, while also touching on how they’d handle load balancing, caching, or security concerns. The point isn’t to complete a “correct solution.” It’s about articulating tradeoffs, constraints, and thoughtful decisions—whether it’s frontend design, backend scaling, or security hardening.

A bad candidate might not even know what an API is. A passable candidate will say “we should use REST.” But the truly outstanding candidate will say, “We could use REST, GraphQL, or WebSockets, depending on X, Y, and Z, and here’s the risk-reward of each.”

The Experience Interview is for Leveling

The experience interview is usually the candidate’s chance to walk through a real project they’ve built or owned. I’ll ask questions like: Who came up with the idea? How many people were on the team? Were there any big missteps? How did you handle them? By exploring how they collaborated, how they solved problems, and what they learned, I get a sense of their leadership potential, growth trajectory, and overall maturity. Airbnb taught me that coding alone can’t distinguish a new grad from a staff engineer—real past experience usually can.

So in short, I want these interviews to answer:

1. Can the candidate code—and how strong are they at it?

2. Are they fluent in architectural reasoning?

3. How seasoned are they, and at what level of responsibility have they operated?

4. Are they disciplined, clear communicators, and generally courteous?

That’s all I really need for a reliable hiring decision. Our scorecard, like many other companies’, is simple: pass each individual interview and earn at least one strong pass from the loop.

But again: the specific interviews themselves matter far less than the clarity of the signal. A “good” interview gives you a crisp read. A “bad” interview yields a bunch of “meh” signals that fail to differentiate among the candidates. If five people come through and they’re all scored as “slight pass,” you haven’t learned anything truly decisive. We killed our longer take-home format precisely because the signal was often muddy. Meanwhile, algorithm interviews, for all their controversy, consistently generate a clear pass/fail/strong pass distribution—and that matters.

Values Interviews: My Evolving Perspective

I used to be a volunteer interviewer for Airbnb’s core values process. It was a robust, multi-day training and something I took pride in. When I started Graphite, I initially cloned that system. But over time, I phased it out for engineering hires—at least in that official capacity—because it wasn’t failing enough candidates who needed to be failed, nor rescuing borderline candidates who might have soared. I wouldn’t pass someone who bombs every technical and architectural interview just because they told a great story about living the company values. Conversely, if they aced everything else, I’m not going to fail them for not delivering a perfect values anecdote.

Today, I still care deeply about kindness, work ethic, and collaboration, but I watch for signs of that during the experience interview (and, honestly, throughout the loop in general). If there’s a glaring red flag, that’s easy to handle. No specialized interview needed. Someday, I might refine or reintroduce a formal values screen, but for now, this simpler approach has worked well.

The Hiring Bar vs. a Hiring Bullseye

There’s a mythic, invisible entity in the recruiting world called “the hiring bar.” Nobody can say exactly what it is, or write it down, yet everyone references it. People wonder, “Are we lowering the bar too much?” or “Is this candidate a bar-raiser?” It’s reminiscent of big tech hiring—Google, Meta, Amazon—where you hire for “generic greatness” rather than specific team needs.

But this can be problematic if the “bar” becomes disconnected from the actual business problem. If you’re not hiring for a specific need—or you simply want to land the best possible people no matter what—then fine, the bar metaphor might sort of work. But for most of us, especially at startups or on smaller teams, we have immediate business challenges that need solving. We’re not just collecting “10X engineers” to keep in a back room; we need real solutions, pronto.

That’s why I prefer a bullseye metaphor:

• Need (the center). What job or jobs are you trying to fill, and what’s the urgency? If your site keeps going down due to Postgres issues, you might need a database expert yesterday. If you have a year to find a security lead, maybe you can be more patient. The clarity around the need shapes everything.

• Risk (the scatter). Even well-designed interviews aren’t perfect. You could end up with a candidate who’s “spiky” and excels in the exact skillset you need—but there’s also a chance they might have big blind spots. If your timeframe is tight, you might be willing to take more risk. If not, you can hold out for a unicorn who checks every box.

The bullseye approach frames hiring as a balance of specificity and risk tolerance, rather than “we have one gold standard bar that we never compromise on.” In fact, a candidate who’s “spiky”—with some yes/no signals—can sometimes be better than a lukewarm, well-rounded candidate if their spikes align perfectly with your need.

Reference Checks: Do Them

Reference checks are often underleveraged because they can be tedious, and hiring managers frequently run out of time or skip them. But they can be invaluable for clarifying uncertainties or revealing hidden red flags.

I think every hire should have at least two named references plus a few blind references (with the candidate’s permission). That might sound like a lot, but here’s why:

1. Named references verify the candidate’s role, anecdotes, and achievements. Did they truly lead that project? Or were they a minor contributor? They also confirm that someone out there is willing to endorse them wholeheartedly.

2. Blind references can deliver incredible insight when they work out. A trusted mutual contact can provide an unfiltered read on strengths and weaknesses, or even share a horror story that won’t come through in a normal loop.

If you’re going to do references, invest the time to ask nuanced questions. And remember: for top candidates, references are also interviewing your company. They’ll often share their impressions with the candidate, so bring your A-game and be consistently thoughtful and kind.

Don’t Hide That Your Process Is Hard

We’re in an era where more companies are vocal about having a rigorous or “high bar” interview process. It might run counter to the typical recruiter instincts of casting the widest net possible, but I’ve found that many of the best engineers want a challenge. They’re selective about teammates and don’t want to be in a place where someone who can barely code is passed along for convenience’s sake.

Being upfront about having a difficult process can actually attract certain high-performers—if you back it up with what one of my favorite recruiters calls “the brilliant basics.” That means you:

• Respond quickly

• Provide a clear schedule and materials in advance

• Treat the candidate with respect

• Give feedback or decisions promptly

• Offer a competitive package at the end

In short, if you’re going to make them jump through hoops, at least hold up your end and run a smooth, respectful process. It’s basic decency, but it also confirms what great candidates are hoping to see: a company run by professionals who care deeply about every detail.

Final Thoughts

Recruiting—especially at scale—is fundamentally about discovering truth and reducing risk. We’re trying to figure out if someone can solve our problems, fit our culture, and thrive long-term. A strong interview loop isn’t about showing off the “correct” method or adopting the hottest new assessment trend. It’s about generating clear signals with minimal noise.

When in doubt, remember:

1. The specific format of your interviews matters less than the clarity of the signal you get.

2. Customize your process to the actual need of the role, not some arbitrary “hiring bar.”

3. Reference checks can be a superpower if you use them intentionally.

4. Don’t be shy about having a “tough” loop—just make sure you execute your end flawlessly.

Ultimately, a robust, fair, and well-structured interview process not only helps you find amazing new colleagues, but it also reassures candidates that your company is serious, intentional, and worth joining. In my experience, that’s the real key to hiring success.

By the mid-2020s, we’ve reached a point where most new software starts as a website (with the typical HTML/JS stack) and later expands to desktop for better ergonomics - whether that’s a direct dock icon, easier OS-level integrations, or just a more focused workspace. Tools like ChatGPT and Perplexity followed this pattern, even if they didn’t necessarily jump on Electron. Still, for many teams wanting to quickly bundle an app, Electron offers near-instant cross-platform support plus coveted “web-style” benefits like automatic updates and zero-friction releases.

When our engineering team at Graphite needed a lightweight desktop extension, we also gravitated to Electron in no time - especially once we saw the auto-updater. But I’ve often wondered: for a framework with such dominance, where exactly did it come from? Turns out the answer is somewhat surprising - GitHub created it.

The Pre-Electron Era

Electron only dates back to 2013, which is not that long ago. Before shipping web apps in desktop wrappers was a thing, developers typically coded fully separate native applications for each platform. Want Mac support? Write Objective-C or Swift and deal with Cocoa. Want Windows support? Roll up your sleeves for C++, C#, or .NET. Linux? Even more configuration fun. Each platform had distinct UI paradigms, code idioms, and build pipelines, so maintaining consistency was a headache. Many teams ended up maintaining two or three codebases, each with its own subtle differences.

A few cross-platform toolkits, like Qt or JavaFX, offered partial solutions but often came with complicated integration layers, inconsistent UI experiences, and occasionally awkward performance. Meanwhile, Java via the JVM was powerful but never felt particularly seamless for consumer-facing desktop apps. Sure, it let you “write once, run anywhere,” but not everyone wanted to wrangle Swing or JavaFX to build a modern UI. And if you needed to ship to the web itself, the JVM wasn’t going to help.

So if you go back to, say, 2010, building a cross-platform desktop app often felt like trudging uphill in two feet of snow.

How Electron Emerged

Enter 2013: Electron, initially called “Atom Shell,” was created by Cheng Zhao, an engineer at GitHub. It wasn’t some altruistic open-source gift - rather, it was purpose-built to power the Atom editor, GitHub’s new “hackable” text editor that relied on web technologies (HTML, CSS, JS) but needed to run on desktop. GitHub funded and nurtured the framework from the start. As a result, Electron quickly benefited from real-world testing, consistent developer feedback, and a large user base - essentially, the Atom community.

Ironically, while Atom itself has been overshadowed by Visual Studio Code, its underlying framework grew stronger and more general-purpose. Within a few years, “Atom Shell” was renamed Electron and reached a solid 1.0 release in 2016. By that point, Slack and GitKraken (among others) had already adopted it. And then came the big one: Microsoft shipped VSCode on top of Electron. That alone legitimized Electron for many enterprise teams.

Under the Hood: Key Technical Choices

Electron’s real breakthrough was embedding both Node.js and Chromium. That allows JavaScript to communicate directly with native OS capabilities while simultaneously rendering a browser-based UI - an irresistible combo for many web developers. The multi-process architecture is roughly modeled on Chromium’s:

1. Main Process: Handles app-level concerns such as creating windows, tying into OS-level APIs, and managing the overall lifecycle. It’s effectively the “brains” of your Electron app.

2. Renderer Processes: Each window or “view” runs in its own process, rendering HTML, CSS, and JavaScript. This isolation boosts stability since a renderer crash won’t necessarily take down the entire app.

3. Auto-Updater: Electron ships with a built-in autoUpdater module. It’s easy to forget that automatic updates have historically been non-trivial in native software. With Electron, you get it with minimal fuss, which is a huge boon for shipping frequent patches or incremental new features.

This structure means a front-end-heavy dev team can push out a desktop version of their web app with minimal friction. It’s precisely why so many startups lean on Electron: time-to-market is usually more critical than memory footprint.

Developer Gripes: Bloat and Redundancy

Electron has faced its fair share of criticism - especially around bloat. Each Electron application bundles its own Chromium instance, so if you’ve got Slack, VSCode, and Discord all open, you’re essentially running three copies of Chrome in parallel. That leads to massive memory usage and large app binaries. A trivial “Hello, world” in Electron might weigh in at over 100MB, which is considered downright monstrous by some purists.

Back in the early days, Electron also had some stability hiccups. Users occasionally encountered “white screens of death” if the renderer crashed. The community eventually hammered away at these, and modern Electron is much more robust. Still, the overhead can be a deal-breaker for teams prioritizing performance and resource usage.

From a security standpoint, Electron apps aren’t typically sandboxed like a modern browser tab. One unscrupulous dependency or an insecurely loaded script could give an attacker deeper access to the OS. For that reason, it’s critical to treat Electron development with the same seriousness you’d apply to native app security: enable contextIsolation, restrict remote code execution, be diligent about packages, and so on. It’s not insurmountable - just requires discipline.

Interestingly, some well-funded apps explicitly avoid Electron. ChatGPT is the best recent example: given that OpenAI has the engineering bandwidth, they built native clients for Windows, macOS, iOS, etc. Some suspect they wanted a deeply integrated experience or better performance (and, let’s be real, if your app name has “AI” in it, you likely care about not wasting cycles). It’s a big ask for a smaller team, though. Most of us don’t have the resources to build and maintain multiple native implementations - hence, Electron remains popular.

Tauri and the Future

Over the years, Electron has radically lowered the barrier to entry for building desktop software. Developers who were once confined to web technologies could suddenly package their work as a native-feeling app - no separate codebases required. That approach sparked new ideas and quick prototypes, brought fresh voices into desktop software, and gave us a wave of tools like Atom, Slack, and VSCode that might have been too expensive to build natively for three platforms. From my perspective, Electron’s real success is how it turned “let’s make a desktop client” from a dreaded, specialized endeavor into just another feasible weekend project.

Of course, not everyone has embraced the memory overhead or the cost of shipping a full Chromium instance with each app. In response, frameworks like Tauri have emerged to solve these exact pain points. Tauri, for instance, relies on the operating system’s native webview instead of bundling its own browser engine. That alone can shrink a basic app’s size from over 100 MB to under 1 MB in some cases. Its backend is written in Rust, which promotes both performance and memory safety, and it enforces more explicit boundaries for which OS-level features the app can access. This is appealing for teams that value security or simply can’t abide a big memory footprint. Tauri is still maturing, but it hints at an intriguing future: one where the convenience of “web tech on desktop” can coexist with smaller binaries and more efficient resource use.

As someone who has followed Electron from its Atom Shell days, I’m struck by its staying power despite these criticisms. For most organizations, time-to-market remains a more pressing concern than raw efficiency, so Electron will likely stay dominant in the near term. That said, the conversation is already shifting. Developers are growing more aware of the trade-offs between convenience and performance, and alternatives like Tauri are stepping up to challenge the status quo. Whether Electron retains its crown or cedes ground over the next few years, it has already changed how we think about desktop apps. It made cross-platform development feel intuitive - even fun - and that’s no small feat.

There’s a myth that building something big—like a company, an open-source project, or any ambitious goal—must feel soul-sucking. That if you’re enjoying yourself, then maybe you’re not grinding hard enough. That perhaps you’re being naïve or soft.

I think that’s backward. Great things do take a long time, but fun is what keeps you motivated for the long haul. Fun is like fuel. It powers you through the late nights, the rough patches, the big pivots—without leaving you burned out, resentful, or at risk of just giving up.

The Biggest Risk: Quitting

Most startups (or big creative undertakings) don’t fail because of lack of money, or a competitor coming out of nowhere. They fail because the people running them give up. And why do founders give up? They’re miserable. They spent years living in a grinding, joyless environment, waiting for some distant milestone to validate all the pain. When the milestone doesn’t arrive on schedule—or arrives and feels anticlimactic—disillusionment sets in. The founder flame goes out.

But what if you never hated the journey? What if you actually had fun building your company or your project? You’d be way less likely to quit, more likely to maintain your energy, and ironically, more likely to reach those ambitious milestones. Because a happy team sticks it out.

Fun in Action: From Apple to Atlassian

If you think fun is a distraction, look at some of the most storied tech teams in history:

• Apple’s Macintosh Team: They worked insane hours, yet they raised a pirate flag above their building and pulled pranks on each other. Even in a pressure-cooker environment, that playful energy helped them produce one of the most revolutionary products in computing.

• Pixar: Scooters in the halls, Nerf battles in the office—they’ve created an entire campus designed to encourage collisions of creativity. Their teams work ridiculously hard under tight movie-production deadlines, but they keep each other’s spirits up and create hits over and over.

• Atlassian’s “ShipIt Days”: Periodically, Atlassian lets employees spend 24 hours building anything they’re passionate about. People form spontaneous teams, eat pizza all night, and ship prototype features. It’s intense, but it’s also fun. Some of their best product innovations originated here.

My Friend Davide

I grabbed coffee with my friend Davide today, a hardware startup founder. He’s about to turn 30, has a long-term girlfriend, and is racing to build something the world needs (he’s even applying learnings from the Mom Test). He’s hustling on every front—building, marketing, selling, hiring. The road ahead looks brutal: the next four years are make-or-break for the company, but they’re also make-or-break for his personal life.

Anyone in his shoes is at risk of doing that “black out and wake up” in a four-year scenario, with 50 employees, a company worth hundreds of millions, but no real lived memories. Conventional success… minus any joy. (Luckily, I think Davide is self-aware enough to avoid this fate - but even then, it’s a risk).

This is the trap. I’ve reached a few “milestones” in my own journey, only to realize how fleeting the celebration feels—sometimes you’re only elated for an hour or two. If you’ve deprived yourself of happiness along the way, the payoff can feel strangely hollow.

My Own Journey Having Fun

I co-founded my current company, Graphite, at the start of the pandemic. It was a weird time: everyone was stuck indoors, often feeling isolated. We could have forced ourselves into a drab, 24/7 grind. But we made it a point to keep it fun.

• We’d go on socially distanced runs together.

• We’d break up workdays with StarCraft II matches—laughing and trash-talking each other, even if it meant staying up late to code afterward.

• We pranked each other by adding hidden memes to the website.

One time, two of us snuck a cartoon weasel into the code so it would flash across the site only for our unsuspecting CEO. Whenever he complained about the bug, we acted like we had no idea what he was talking about. This went on for a month, until a customer demo was interrupted by the little blue weasel. We had to come clean, but it was worth it—everyone had a blast, and we still got our work done, sometimes staying even later because we were enjoying ourselves.

Strength in Positive Rituals

It doesn’t have to be elaborate or expensive. Just do small things that break up the monotony:

• Work a week from Mexico: New sights, sounds, food, and cheap flights can recharge everyone’s creative batteries.

• Team Meals: Order good takeout or open a bar tab after hitting a milestone.

• Healthy Social Activities: My cofounders and I used to do a weekly $100 shared restaurant meal to talk openly about our biggest challenges. Now, we’ve upgraded it to a regular bathhouse hang—three hours of sauna, cold plunges, and conversation. We usually keep talking and working until 10 pm because we want to.

• Random Hackathons: Let your engineering or design team drop what they’re doing for a day and build something fun, weird, or purely experimental. One engineer on our team built a Resy bot that we all abused for a year to get the best Soho reservations.

• Pranks & Inside Jokes: They’re silly, but they build trust and lighten the mood.

Think of these moments as insurance against burnout. Fun is not fluff—it’s an asset that keeps morale high, fosters tighter bonds, and extends your team’s runway.

The Goal: Don’t Die (and Don’t Quit)

Plenty of legendary companies faced extended slowdowns or near-death experiences. HP started in a garage, Google took a while before AdWords became a big moneymaker, and countless open-source projects simmer for years before they blossom. The founders who stuck around weren’t necessarily the ones who loved stress; they were the ones who made life sustainable.

• If you stall out for a year or two, do you really want to keep pushing if every day is joyless? Probably not.

• But if you and your cofounders are still having the occasional laugh, still doing weekly runs or monthly pranks, the idea of continuing feels a lot less painful.

The “fun factor” is a hedge against the single greatest threat to any big venture: giving up.

Hard Work Doesn’t Have to Be Joyless

None of this is to say that real grind and intensity aren’t part of the journey. You might be pulling all-nighters, shipping code at 2 am, or traveling nonstop to meet investors. That’s part of the deal. But it’s orthogonal to having fun. You can do both simultaneously. If Pixar can animate blockbuster films under insane deadlines and still ride scooters in the halls, if the original Mac team could brand themselves as “pirates” while cramming for product demos, there’s proof it’s possible.

In fact, the positivity might even enhance the grind: if you genuinely enjoy being around your team, you’re more likely to work those extra hours without resentment.

1. Life is Short: The journey is everything. If you hate the journey, you might hate your life.

2. Fun Powers Momentum: Tiny doses of fun—an hour at the gym, a bar tab, a hackathon, a silly meme in the code—can keep you going through tough times.

3. Less Likely to Quit: A culture that embraces fun is infinitely more sustainable and less prone to founder or team burnout.

So I’ll say it again: Make your work fun. Try a new environment, plan a team-building prank, or schedule a “ShipIt Day.” If you’re working on something great, you want every advantage to keep you going for years. And if you end up missing the milestone? At least you won’t regret the time you spent—and you might even surprise yourself by persevering until the big win finally hits.

I began my career as a new-grad software engineer at Airbnb, where I got a crash course in all things tech: building new services from scratch, refactoring old systems nobody wanted to touch, getting paged at 2 a.m. to fix production outages, collaborating with PMs and designers, and yes, inevitably breaking the site more times than I’d care to admit. I loved it. As an IC, you learn to focus on shipping code. Whether you’re writing design docs or squashing bugs, there’s always the tangible thrill of solving a problem by turning it into a neat little pull request.

Eventually, though, I realized my passion wasn’t just about making good software—it was about building the team that makes software. I found my way toward co-founding a company, Graphite, where our mission is to create developer tooling that helps other teams ship better code. That means we’re essentially an engineering team that builds software to help other engineering teams build their software. My parents may never understand what that means, but I find it incredibly rewarding.

As Graphite grew, I noticed that the scope of my responsibilities had shifted. I was no longer just heads-down coding. Instead, I found myself reading up on management best practices, talking to seasoned engineering managers, and even hiring a leadership coach, all to help me become an effective leader for our growing team. Over the past few years, I’ve hired, let people go, coded in the trenches, run weekly standups, delivered tough-love feedback, dealt with product and roadmap debates, and everything else you can imagine. Now, I’m lucky enough to be mentoring two of our own engineers in their journey to become managers themselves, which has forced me to articulate the often fuzzy question: “What is the job of an engineering manager, really?”

Below is my best attempt at answering that question from the vantage point of an early-stage startup environment. It won’t be the last word on the subject, but if you’re navigating or considering the leap from IC to EM, I hope this helps.

The Real Job of an Engineering Manager

An IC’s job is to build things. It might sound obvious, but it’s worth stating explicitly: the primary responsibility of an individual contributor is to write, review, and ship meaningful code. While collaboration, design reviews, and planning are all critical, the fundamental output of an IC is the codebase changes that push the product forward.

A manager’s job, by contrast, is twofold: (1) build and maintain context, and (2) apply that context to help the team make better decisions. That’s it in a nutshell. But what does “context” really mean, and why can’t an IC just keep track of it themselves?

Building and Maintaining Context

A manager should have a bird’s-eye view of the organization: upcoming product launches, the company’s financial outlook, the top priorities of adjacent teams, the morale and burnout levels on their own team, as well as the big architectural pain points lurking in the codebase. You become something of a “information sponge.” You’re reading Slack threads, attending product reviews, talking with design, keeping an eye on bug metrics, and noticing who might be hitting a wall or feeling frustrated.

It might take half of your week to keep up with this swirl of information. Maybe more. Early in my own transition, I felt uncomfortable spending too much time in meetings or Slack. But the reality is that building this context is the core part of the manager’s job. If an IC tried to absorb all of these details, they would never have time to get into the flow state required for deep, productive coding. That’s why the org needs a manager to do the heavy lifting of data collection and synthesis.

Where do you get this information? From team standups, one-on-ones, coffee chats, incident postmortems, and countless impromptu conversations. You read design specs, watch product demos, and poke around your analytics dashboards. You also need to invest in genuine human relationships. People will share crucial, often delicate tidbits of information only if they trust you. That trust is built over time, through honest conversations and genuine care.

Applying That Context

Once you’ve built a robust picture of what’s going on, you deploy that context in targeted moments. You might be in a planning meeting where people are debating whether to tackle a new feature or refactor an old system. Drawing on your knowledge of the product roadmap, the team’s workload, and the relative importance of tech debt, you can cut through the noise to advocate for the best course of action. You might be sitting down with a high-potential IC who wants to grow into bigger responsibilities; your breadth of perspective helps you give pointed feedback on where they should focus their efforts. Or you might sense that morale is dipping because the team hasn’t shipped something exciting in a while, so you convene a brainstorming session to get people jazzed about a new initiative.

A manager who fails to build context can only offer generalities, like “Let’s just do what’s best for the user.” But a manager with deep context can back up their decisions with specifics: “We can’t prioritize this new feature right now because we’re already committed to a major migration by the end of the quarter, and if we delay that, we’ll blow up next quarter’s product timeline. Plus, I know half the team’s been on-call too often, so adding more complexity now would risk burnout.” That’s powerful, targeted leadership—only possible when you thoroughly understand the landscape.

The Path to Mastery (and a Beating Heart to the Team)

Becoming truly great at engineering management means refining those two skills—context-building and context-application—until it looks almost effortless. You arrive at meetings armed with detailed knowledge, but you don’t bury people in it. Instead, you deliver the critical points with clarity and tact. You sense when someone’s on the verge of feeling overwhelmed and schedule a quick check-in, or you notice that a project is behind schedule but also see that your PM is overcommitted, so you jump in to realign resources and reset expectations.

Managers often shoulder the formal processes that come with running a team—performance reviews, hiring decisions, roadmap planning, conflict resolution—and these tasks can feel large and intimidating. Yet they are fundamentally just high-leverage moments to apply your context. If someone isn’t hitting expectations, you have the bigger picture of why. If a key candidate is on the fence about joining the team, you can share insights on future product vision and the cultural environment. If a product manager wants to double down on a risky feature, you can offer data on capacity, highlight morale concerns, or compare the opportunity cost with other initiatives. Good managers are always integrating the specifics of the situation with the broader narrative, ensuring decisions serve both immediate goals and the company’s long-term health.

At times, you’ll hear the analogy that a manager is like the “beating heart” of the team, circulating information around the organization the way a heart pumps blood to the limbs. ICs are the “hands and feet” doing the visible work that moves the product forward. Without the manager’s steady circulation of context, the system would lack coordination, starve for resources, or chase conflicting priorities. Conversely, a heart without limbs wouldn’t accomplish much in the real world.

What makes a manager “amazing” is the ability to blend those big-picture insights with genuine human connection. People trust you to represent them well in leadership discussions. They know you’ll catch subtle signals—like a developer who’s close to burnout or a new hire who’s still unsure about their place on the team—and offer targeted support. Over time, your calls on hiring, promotions, or roadmap decisions earn a reputation for being smart, fair, and correct more often than not. The credibility you build in these moments leads people to share even more context with you, which further enhances the quality of your decisions. It’s a virtuous cycle where strong relationships lead to better insight, which leads to better interventions, which reinforces those relationships.

In short, an effective engineering manager is a trusted node of information flow and a decisive guide who can marry that context with good judgment—whether it’s helping a junior engineer navigate a tough design problem or steering the entire team away from a low-impact project. The closer you get to that blend of empathy, clarity, and accuracy, the more you’ll embody the heartbeat that keeps your organization healthy and thriving.

Recommended Reading and Closing Thoughts

If you’re new to management (or contemplating the leap), I highly recommend reading The Manager’s Path by Camille Fournier for a practical roadmap of the journey from IC to CTO, as well as High Output Management by Andy Grove for a fundamental look at how to lead teams effectively. Books like The Making of a Manager by Julie Zhou can also offer valuable insights into daily leadership habits and common pitfalls.

Ultimately, if you’ve ever felt the pull to influence how your team collaborates and how decisions are made—and not just how code is written—there’s a good chance you’ll find fulfillment on this path. Yes, you’ll spend less time coding, and yes, you’ll probably spend more time in meetings than you ever thought possible. But done right, management is a profoundly creative and impactful role. You’re still “building something”—only now, instead of just writing code, you’re building and shaping the people, processes, and culture that make the code possible.

That’s the essence of being an engineering manager in an early-stage startup: you’re the heart that circulates knowledge and keeps the team moving in sync, while your ICs are the skilled hands doing the bulk of the visible work. Both are essential, and when done well, each amplifies the other. If you can master these complementary roles—absorbing context and delivering it at the right time—you’ll find that managing engineers can be every bit as satisfying as building the product yourself.

It’s a story that rubs some people the wrong way: there’s a natural pushback when someone tries to defeat a universal part of the human condition (i.e., aging). And, as scientists in the documentary noted, one individual’s relentless n-of-1 experimentation doesn’t immediately revolutionize science. But if you look beyond his pursuit of “don’t die,” Johnson strikes me as someone who:

• Tries to be kind and positive. (Example of him being kind in the face of a Twitter troll).

• Shares what he learns but doesn’t shove it down anyone’s throat.

In contrast, I hate reading headlines of founders bragging about how many raw hours they make their teams work. In many cases, when you dig into it, these teams are pitifully productive for their time burned. It’s unhealthy and a narrative that I hate to see perpetuated.

Bryan Johnson opens up about the same topic in the documentary. When reflecting on his grinding work ethic at Braintree, he talks about how the unhealthy culture led him to dark depression and suicidal thoughts:

I do not fear death. I sat at its doorstep for a decade alongside chronic depression. Desperately wishing I didn’t exist. Had it not been for my three children, I probably would have taken my life.
https://x.com/bryan_johnson/status/1683261029281861632

By this measure, I don’t find him offensive. If anything, I admire his curiosity and his advocacy for general health. The controversy arises when you take something as fundamental as aging and say, “Let’s see how far we can push this.” And yet, it also made me ask a fun question: What would the engineering equivalent be?

I spend a lot of time working on developer tools—things that measure productivity, help teams ship better code, and encourage best practices. So naturally, when I see Bryan Johnson pushing the limits of human health, I start to wonder: How far can we push the “health” of an engineering organization?

The (Sometimes Awkward) Parallels

In health, you’ve got the Hubermans and Bryan Johnsons of the world bringing attention to metrics, interventions, and ways to improve longevity. In software, many of us are doing the same for engineering velocity. It’s nowhere near as existential as not aging—but the desire to “ship fast” and find new productivity frontiers does mirror the relentless optimization we see in health circles.

There’s an obvious counter-critique to chasing engineering productivity: “Why are you obsessing over metrics and throughput? The point of software isn’t just to do more, it’s to build something valuable.” Fair question—just like people ask whether the obsession with living longer comes at the cost of living well. We see it in Bryan Johnson’s lifestyle: is the joy of daily life compromised by 100 pills and rigid routines?

For an engineering team, there’s a similar risk. If you over-optimize for raw productivity (lines of code, PR count, etc.), you might forget about the delight or user value that software should bring. So if you do decide to push the limits on engineering speed, it’s important to be clear about the purpose: it’s not to create an iron-fisted roadmap that everyone must follow, but to explore what’s possible and see what useful techniques can trickle out to the broader dev community.

Measuring the Extreme Edge

In practice, a quest for “the most productive engineering team” will produce tons of new questions:

• What counts as productivity? Is it PRs per day, deployments per week, or something else entirely?

• How do we account for team happiness, code quality, or ultimate business impact?

• Is raw speed even the right goal?

I like the analogy to Bryan Johnson because he’s not claiming everyone should mimic him. He does the wacky stuff precisely because it might illuminate a path for new discoveries and knowledge. Similarly, an engineering team that pushes extreme optimization might glean patterns—maybe around code review cadence or PR sizes—that other teams can apply in moderation.

In my own work, analyzing tens of millions of pull requests has already revealed interesting data: the ideal median PR size for velocity, the sweet spot for CI duration, how certain repository sizes benefit from ordered merges, and so on. These patterns help guide how we build tools and talk about best practices. Our internal team has ended up in the top percentile of PRs-per-engineer metrics just by living these approaches day in and day out. But there’s still plenty more to learn, so I’m starting to measure productivity more systematically.

Take the “DX Core-4” from DX. Here’s a snapshot of how Graphite’s engineering team totaled up in Q4 2024:

• Median diffs per engineer per day: 6

• Developer experience index: (still to be measured)

• Change failure rate: 1.05% (the probability that any single PR causes us to pause deployments)

• Impact: 24% (percentage of merged PRs marked as “feat” in conventional commit style)

Even computing these numbers raised big questions: Which metrics are the best benchmarks? What’s “good” or “industry standard”? When does the quest for speed overshadow code sustainability? (Luckily, it’s easy to agree these are at least healthier measurements than hours-per-week worked.)

That’s the messy part of productivity research—every answer breeds new questions. But I do think there’s value in trying. Even if not everyone needs to be hyper-productive, a segment of teams pushing the envelope can surface best practices that benefit all. The same logic that justifies Bryan Johnson’s experimentation might justify an engineering team’s: it helps us learn, debate, and evolve.

Should anyone mimic these measures to the extreme? Probably not. Software teams exist to create value for the world; shipping speed is just a means to that end. Still, I believe in leaning into these experiments—and in sharing the results openly, the successes and the stumbles. If it helps even a fraction of teams discover ways to work more effectively (and maybe with fewer pains along the way), then the experiments are worth it.

If this post piques your curiosity—or makes you roll your eyes—great. We need the skeptics who say, “Why the obsession with shipping speed?” just as much as we need the folks who say, “What’s the absolute limit of code velocity?” Somewhere between these extremes lies a healthy middle ground, informed by the outer edges of experimentation. And if a little self-awareness can keep it from devolving into an engineering version of “don’t die,” I’ll count that as a success.

Where’s my opinion come from?

I’m not here to claim that I’m a 10x developer—saying so would be wildly arrogant. But I’ve been around engineering for 15 years, spent time in the trenches with some absolutely brilliant ICs, and helped build engineering tools for folks at Snowflake, Asana, Brex, Ramp, and Square. I co-founded a startup dedicated to making code review faster (and hopefully less painful). Through it all, I’ve seen firsthand what separates the “good” from the unbelievably impactful.

What Is a 10x Engineer?

When I say “10x engineer,” I don’t mean someone who writes 10 times more code or who logs the most hours. I mean someone who produces 10 times the impact—on the product, the business, or the users’ actual lives. It’s outcomes-focused, not input-focused.

Does a 10x engineer often crank out code faster than me? Sure.

Do they sometimes have a knack for debugging or a stellar sense of architecture? Absolutely.

But none of that matters if they don’t produce tangible, disproportionate impact.

A Crazy Elon Musk Story

Let me share a heavily condensed (but still entertaining) anecdote from Elon Musk’s takeover of Twitter/X. The company was spending a fortune on a data center in Sacramento. The internal estimate was that migrating 5,200 massive server racks to a cheaper data center in Portland would take months, because, of course, big data centers have all these security protocols, specialized moving equipment, etc.

Musk, being Musk, decided that was too slow. So, in December—right around Christmas—he and a couple of family members literally hopped on a plane, diverted to Sacramento, rented a Toyota Corolla, and started pulling servers themselves. They pried up floor panels with a pocketknife, hired a motley crew from Yelp, and strapped these 2,000-pound racks onto trucks like college kids moving out of a dorm. In a matter of days, they moved hundreds of servers (something that normally would take weeks or even months).

Of course, chaos ensued. Some servers still had user data. NTT, the company that owned the data center, wasn’t thrilled. X missed stable capacity for a bit, which caused meltdown moments—like that infamous Ron DeSantis Twitter Spaces fiasco. But from one angle, it was a 10x success: They slashed a task initially planned for months down to mere days. The cost savings were enormous, but the tradeoff in downtime, staff morale, and sleepless nights was real.

So—both inspiring and cautionary.

(Full story here, it’s a fun one: https://www.cnbc.com/2023/09/11/elon-musk-moved-twitter-servers-himself-in-the-night-new-biography-details-his-maniacal-sense-of-urgency.html)

The 10x Formula

What can we take away from that story (and others like it)?

1. Start From the Biggest Problem

Don’t spin your wheels on a 2% optimization if there’s a huge cost sink somewhere else. The best engineers I’ve worked with target the single most important driver of business or user pain. Then they go straight at it like a dog on a bone.

2. Rewrite the Rules (If Needed)

The timeline is “6 months.” Is that actually carved in stone? Maybe if you push or skip steps, you can do it in 3 weeks. Conventional thinking says you need an official moving team, or 27 approvals, or a detailed project plan. A 10x engineer questions all of those assumptions, sometimes ruthlessly.

3. A Big Appetite for Risk

When Musk & Co. started yanking servers, they risked data breaches, hardware damage, and definitely a few lawsuits. That’s an extreme example. But being 10x often means tolerating short-term mess or even stepping on toes if it yields enormous, disproportionate wins. (I’m not saying break the law—just know that 10x speed can come with some friction.)

Uber famously had an original core value of “toe stepping,” but later removed it to limit asshole behavior

4. First-Principles Pragmatism

Musk pried open the floor panel with a knife to see if it was “actually that complicated.” It wasn’t, or at least not as complicated as the vendor made it sound. Similarly, when you find yourself debugging or architecting, ask, “Is there a fundamentally simpler approach if I ignore conventional wisdom for a second?”

5. Own It, Do It, Ship It

This is the difference between someone who complains about blocked JIRA tickets and someone who drives to the data center themselves at midnight. 10x engineers take personal responsibility. They embody “If it has to be done, I’ll figure it out.”

Examples of Straight-Line Engineering

The Elon story is great, but it isn’t about software engineering. Here are some more relatable examples of achieving root impact ten times faster than default.

Overnight Debug

Your flagship service is crashing in prod, costing thousands per hour. Instead of logging a Jira ticket and waiting for triage, you convene a quick 15-minute huddle with your manager and SRE lead to get sign-off on direct debug logs in production. By 1 a.m., you’ve identified the culprit and shipped a patch, saving days of formal process.

Last-Minute Feature Demo

Sales surprises you: an important client wants a specific feature demo in one week, not the planned three months. You corral product, design, and QA into a mini “war room” and strip the scope to the bare essentials. After a rapid round of Slack approvals, you ship an MVP that impresses the client—ugly corners and all.

Monolith-to-Microservices Blitz

Your team faces a massive, six-month plan to decompose a legacy monolith. When leadership demands tangible progress in a single sprint, you copy the entire codebase into multiple smaller repos overnight. It’s hacky, but now each squad can start carving out features on their own timeline, effectively creating a microservices setup in record time.

Hotfix in Production

A critical security flaw surfaces late on a Friday afternoon. Rather than scheduling an urgent sprint or forming a governance committee, you grab the security lead and DevOps for a quick risk assessment and swift approval. You patch the vulnerable code directly in prod and monitor logs over the weekend, nipping the issue before it becomes a PR nightmare.

Data Pipeline “Weekend Hack”

Your analytics pipeline is bogged down, threatening key reporting SLAs. The official solution—comprehensive refactoring—will take two sprints, so you pitch a fast weekend hack to the data team: bulk-export to staging servers, parallel-process, and re-import Monday morning. Everyone agrees to this duct-tape fix, restoring performance quickly while planning a better long-term approach.

The Human Side Matters

In all these hypotheticals, the real magic isn’t coding or hacking alone. It’s how you question default assumptions and secure rapid alignment:

• You communicate early and clearly about risks.

• You involve the key people needed for sign-off.

• You negotiate a shared understanding of what will be sacrificed short-term.

That’s often the difference between a 10x solution and a reckless one. A solution is “reckless” when you bulldoze ahead solo and surprise everyone. A “10x solution” is when you do that same direct path with your team’s backing and an agreed-upon plan to handle any fallout.

The Very Real Downsides

1. Collateral Damage

Elon’s server escapade cost some employees their Christmas Eve, put user data at risk, and caused company leaders to freak out. Similarly, doing things at 10x speed can blow up your personal life, damage trust, or lead to corners cut. If everyone at your company tried to do this all the time, you’d have pure chaos.

2. Accumulated Mess

Shaving 10 months off a project often means the code is loaded with duct tape. You can fix that later—hopefully—but you might end up with 100 small fires that never get the attention they deserve. If you keep sprinting from big problem to big problem, you eventually need a “cleanup day.” Or three.

3. Burnout and Thanklessness

Putting in heroic hours and ignoring conventional processes can be exhilarating at first. But if you rely on external praise, you might end up feeling under-appreciated. Sometimes a 10x success will just lead people to assume that’s your normal pace and set expectations even higher next time.

4. Not for Everyone, Not All the Time

Realistically, not everyone wants (or needs) to operate at 10x mania. Teams also need methodical, detail-oriented engineers who ensure quality and keep the lights on when the 10x folks inevitably break something.

Do You Even Want to Be 10x?

You don’t have to. You’re not a lesser engineer if you operate at a steady clip, write clean code, and value stable processes. Seriously. Some workplaces thrive on consistent, methodical improvement—and a 10x renegade might actually hurt them.

But if you do see a chance to drive massive impact and want to push every lever you’ve got, here’s the short version:

1. Identify the biggest, hairiest problem.

2. Forget the usual timeline—ask how you can do it 10 times faster.

3. Accept the possibility of chaos, conflict, or short-term ugliness.

4. Get scrappy, do the work yourself if you must, and don’t stop until it’s done.

Success here is measured by the impact on customers, revenue, or critical product metrics—not by how many new lines of code you wrote or how impressed your peers are with your commit history. And even if you choose not to execute on the straight line path, sometimes brainstorming can be a worthwhile exercise in planning.

There’s a misconception that 10x is just about being the smartest person in the room, writing immaculate code at superhuman speed. Really, it’s about focusing relentlessly on results, questioning constraints, and taking personal ownership. It can be exhilarating, disruptive, and at times disastrous.

But if you deploy it wisely—knowing the tradeoffs—you can occasionally pull off the impossible, shave months off timelines, and deliver massive wins. And if that’s something you’re itching to do, hopefully now you have a playbook. Just remember: “best practices” exist for a reason, and you’ll eventually have to come back to clean up your trail of destruction.

Pick your battles. Keep your eye on the prize. And if you decide to be a 10x engineer for a moment—do it with clear intent, accept the risks, and own the outcome. After all, impact is the name of the game. Everything else is just process.

Charging for software has always been a tricky business, and I’ve watched firsthand how it’s evolved. In the consumer world, the early App Store days saw a quick one-time fee of a few bucks for an app, yet developers still had to shoulder an ongoing burden of updates and maintenance. We learned that subscription models often made far more sense—both for recouping the continuous costs of building software and for matching the actual value delivered over time.

In the business world, that realization hit even earlier. Microsoft and Adobe used to sell annual licenses for their products, but now pretty much everything has moved to monthly or annual subscriptions. That, in essence, is SaaS (Software-as-a-Service), where customers pay recurring fees, typically per seat, for software access, support, and upgrades.

Why Per-Seat Pricing Made Sense for So Long

Per-seat pricing took hold for a few reasons:

1. Simplicity and Alignment: Paying by user felt straightforward for both finance teams and product teams. As headcount grows, so does usage—and the bill.

2. System of Record: Many of the best SaaS products evolve into a company’s central repository (think Slack’s messages, Notion’s docs, Figma’s designs). Because that data can be mission-critical, businesses often want everyone to have a seat, ensuring no one is locked out.

3. Predictable Revenue: On the provider side, it’s fairly stable. Each new user is new revenue. That’s made planning and growth forecasts easier.

The Downside: Economic Shifts and Headcount Reductions

As great as this model seems, it can create serious vulnerabilities during economic downturns or mass layoffs:

• Immediate Revenue Loss: When a company shrinks its workforce, that triggers an automatic drop in paid seats.

• Budget Scrutiny: Tightening the belt often leads to prioritizing which tools truly matter. Anything considered non-essential can get dropped or scaled back.

We saw net-dollar-retention (NDR) dip at many SaaS companies during recent slowdowns. That’s painful because it sets off a cycle of cost-cutting on the SaaS-provider side, which doesn’t do any favors for innovation or morale. Historically, the sector bounces back once the economy recovers, but per-seat pricing remains especially exposed to workforce fluctuations.

The AI Angle: Fewer Humans, Same (or Greater) Output

An even bigger wild card now is artificial intelligence. As code generation and large language models continue improving, it’s not inconceivable that fewer engineers or analysts can accomplish the same workload. I’ve had conversations with multiple VCs about whether the widespread adoption of AI will shrink the total number of employees at a company who need access to certain tools. It’s still speculation, but I think it’s fair to say it’s where many of the biggest tech companies and investors think the market is heading.

For a per-seat SaaS vendor, this is an existential threat. If, say, a 50-person engineering department becomes a 30-person department thanks to AI boosts in productivity, that’s a 40% seat reduction. Multiply that across thousands of customers, and you suddenly have major downward pressure on the revenue model.

Rethinking the Pricing Model

If AI truly reshapes headcount, seat-based pricing might have to take a back seat. Here are a few alternative models I’ve been thinking about or observing:

1. Usage-Based

• Datadog Example: You pay per log, metric, or trace consumed. It’s great for onboarding—minimal friction—but costs scale with usage. The risk is that some customers might try to limit usage to keep costs down, which can undercut the inherent value of the software.

2. Compute/Consumption Model

• AWS Model: You’re billed for compute time, storage, and data transfer. If AI-driven workloads grow, they’ll naturally require more compute. This ties revenue to actual resource consumption rather than to the number of humans using the platform.

3. Reads vs. Writes

• One idea I’ve heard (and like) is making “writes” free and then charging for “reads.” Creating and storing new data is essentially free, encouraging more data in the system, while reading or analyzing that data is where incremental costs kick in. Slack’s approach to old messages—paying for historical access—kind of nods in this direction.

4. Freemium Hybrid

• Attract a broad user base with free or low-cost seats, but charge heavily for advanced features, more storage, or AI-driven insights. This can widen the top of the funnel without giving away too much value for free.

The Facebook/X Paradox

Though it’s a B2C example, Facebook’s model of free user creation but monetized reads (ads) is fascinating. X (formerly Twitter) is also experimenting with a subscription that effectively lets you pay for an ad-free reading experience. In the B2B world, we could see SaaS companies offering free seats for everyone to create and collaborate, yet charging heavily for higher-value interactions like analytics, AI-driven recommendations, or large-scale data queries.

Value capture will need to change

I’m personally convinced that system-of-record software will be more essential than ever, even if a company’s seat count drops. AI runs on data, and it needs somewhere to “live.” The question is how to monetize in a world where the number of human users may not be the best proxy for how much value is being created.

Sometimes, the answer might be usage-based or compute-based billing. In other cases, maybe it’s a more creative model that charges for action and insight rather than people. But if AI truly delivers on its promise to reshape the workforce, the per-seat pricing structure could look more like an artifact from a different era.

I suspect we’ll see more SaaS businesses shift to these alternative models in the next few years—partly due to macroeconomic forces and partly because AI is challenging every assumption about headcount-based metrics. If the seat count in a typical organization does begin to shrink, I believe those who adapt their pricing to reflect actual resource consumption, data access, or compute cycles will be in a better spot to survive and thrive.

I get asked—a lot—to build a self-hosted or on-prem version of Graphite. I usually respond with a line I borrowed from Datadog’s philosophy: I’ll never say no; I’ll just quote an extremely high price. Why? I want to maximize our team’s itteration velocity. Over the years, I’ve seen how the on-prem conversation can shape product roadmaps and company trajectories. It’s rarely as simple as saying, “Sure, we’ll just let you host it yourself.”

It’s interesting how far the SaaS industry has come. In the early days of software, there was no concept of “the cloud”—everything was on-prem because that was the only way to ship code. If you look at the 1960s and ’70s, entire businesses were built around selling software licenses for mainframe computers. In the ’90s and 2000s, though, the internet and cheaper hardware flipped that model on its head. Companies like Concur (for expenses) and Salesforce (for CRM) opened a new world of web-based solutions, paving the way for SaaS as we know it.

These days, we think of cloud-hosted SaaS as the default. The typical benefits are pretty well-documented: no huge hardware investments, easy scalability, and remote accessibility. But that same rise of cloud-based software also created tension in industries where control, security, or compliance is paramount. While some companies (Datadog is a famous example) have maintained a hard line on staying fully cloud-hosted, many others end up building an on-prem offering as soon as a lucrative enterprise contract comes knocking.

I can relate. It stings to turn down seven-figure deals just because you don’t want to offer an on-prem deployment. But there’s a good reason so many teams hold out as long as possible: the additional complexity is enormous, and it directly impacts how quickly you can ship and iterate.

On-Prem Slows You Down

I believe that the most essential principle in software engineering is iteration speed: ship fast, learn, tweak, repeat. Software is uniquely “soft,” meaning you can push an update at almost any time—unlike physical products that are locked in once they leave the factory. On-prem, however, grinds that magical quality to a near halt. Let me explain why.

1. Observability

In a standard cloud setup, you can instrument your application to gather metrics, logs, and performance data right in your own environment. With on-prem, you’re effectively deploying your code into someone else’s data center. You have to build custom reporting frameworks that “phone home” with usage data—or you settle for flying blind. Either way, you lose the seamless real-time insight you’d otherwise have.

2. Debugging

This is where it gets really messy. If a customer hits a weird bug in an on-prem environment, maybe it’s your application logic. Or maybe their load balancer is misconfigured, or their OS is on a strange version of Linux, or the database is at capacity. Reproducing that bug often means reconstructing their entire environment, which they may not want to share. Even if they do, it’s a time sink that quickly kills your iteration speed.

3. Shipping Updates

Let’s say you nail down the bug, fix it, and build a shiny new feature while you’re at it. How do you deliver those changes? Are you begging your customers to run manual upgrades? Automating behind the scenes? What if you need to perform a database migration—do you schedule downtime or risk doing it live? Suddenly, something that’s trivial in a SaaS world becomes a multi-step negotiation for each and every customer environment. The problem is uniquely painful enough to inspire startups dedicated to smoothing the process.

All this grinds velocity to a halt. On-prem can make product iteration painfully slow, draining resources you’d rather spend building features. For most early-stage companies—startups especially—that slow speed is lethal.

Potential Workarounds

That said, I understand not all businesses don’t have the luxury of turning down self-hosting requests. There are some creative ways to satisfy the control and compliance needs of certain customers without sacrificing too much velocity.

Single-Tenant Cloud

You can run a dedicated instance for each customer in your own cloud environment. Teleport calls this a “private cloud” model. This approach keeps your observability and debugging mostly intact and eliminates your customer’s hardware overhead. You still have multiple instances to manage, but you can generally push updates more frequently than you could with pure on-prem.

Customer VPC with Remote Ops

Sometimes you can deploy into the customer’s VPC and ask for IAM permissions so you can troubleshoot or run upgrades on their behalf. That approach offers them the comfort of hosting in their own environment while still giving you some level of access to debug.

Embedded Engineers

Palantir famously uses forward-deployed engineers who work directly inside customer organizations. This is overkill for most companies but can be worth it for a massive contract. Your team effectively becomes the ops team within the customer’s environment—solid for debugging, but not scalable for smaller deals.

Will On-Prem Ever Disappear?

I doubt it - though most SaaS founders would wish different. Life is easier when your code runs in one place (your own cloud infrastructure) and you can deploy updates at will. But certain industries—healthcare, military, finance, advanced AI—will always push for maximum secrecy. They’ll say, “you can’t dare see our data,” and that typically means you have to put the actual compute in their environment.

I’ve dreamed of building tools that operate on encrypted data without ever decrypting it, but it’s not generally viable for the average SaaS app right now. We do see some neat hybrid architectures emerging—like Tecton’s or Datadog’s—that split the difference by running data-processing components inside the customer’s VPC while hosting the rest of the logic in a central cloud. It’s a promising direction, but it doesn’t completely solve the fundamental tension between velocity and on-prem demands.

If you’re just getting started, my recommendation is pretty straightforward: either go all-in on on-prem as a key selling point (like Sourcegraph did) or avoid it altogether for as long as you can. The market of customers who don’t require on-prem is huge—often big enough to get you to product-market fit and beyond.

Introducing on-prem too early can slow you down and distract you from making your product great for the majority of your users. Eventually, you might decide it’s worth addressing specific high-paying segments, but only when you have the resources and stability to handle the complexity.

At the end of the day, iteration speed is the beating heart of a healthy software business. On-prem can be a serious drag on that heartbeat. Approach it with your eyes open, weigh the trade-offs, and decide if the revenue is truly worth the slowdown.

Disclaimer: This post is based on my own experiences and research - it’s possible I got some details wrong. Feel free to correct me on anything if you have extra historical context!

When I think of Atlassian, I envision a B2B SaaS powerhouse that somehow stayed (comparatively) under my radar most of my career. Despite being around for 20-plus years, it didn’t infiltrate my daily workflows as much as you might expect for a company of its stature. Sure, I would see Jira tickets at previous jobs or occasionally spin up a free Bitbucket repo in college. But those moments were few and far between.

At Airbnb, we used Jira to keep track of infrastructure fires - everything from urgent server issues to recurring tasks. In theory, that system would have kept our entire team in sync. In practice, we were moving so fast that a lot of tickets were either skipped or closed retroactively after we’d already solved the problem. On the version control side, when I was a broke college student, Bitbucket caught my attention simply because it let me have a private Git (originally Mercurial) repo for free. That was a lifesaver for group projects and side gigs - otherwise I would’ve had to pay GitHub for private repos at the time.

For me, Atlassian was always a bit like a giant in the corner - clearly huge and successful, but not always at the forefront of my personal toolset. And yet, nearly every large enterprise I’ve encountered has some piece of the Atlassian stack. So, how did it become this quiet yet colossal force in software collaboration?

The Early Days: Bootstrapping Through the Dot-Com Bust

Atlassian’s story goes back to 2002, right on the heels of the dot-com bubble bursting. According to their historical timeline, the founders - Mike Cannon-Brookes and Scott Farquhar - met at the University of New South Wales and launched the company with about $10,000 of personal credit card debt. They bootstrapped their way through that initial period, largely because venture capital was scarce and attitudes toward risky tech investments were pretty sour.

I’m unbelievably spoilt working on a startup in the 2020’s. I have massive respect for them bootstrapping Atlassian for 8 years on personal debt.

At a time when many startups were either dying off or scrambling for any available funding, the founders stuck to selling on-premises licenses of their early products. They kicked things off with Jira, a bug-tracking/issue-tracking tool, and soon after introduced Confluence, a wiki-based collaboration platform. This was bold: while a lot of companies were pivoting or folding, Atlassian was doubling down on a bottom-up, product-led growth approach. Their bet was that developers and tech teams would champion the tools if the tools were good enough to solve real-world pains - no big sales force required.

A huge part of Jira’s success lay in its elegant concept of the “ticket” as an atomic unit of teamwork. Tickets could track bugs, tasks, or anything else that needed some measure of accountability. Competitors at the time included open-source solutions (like Bugzilla) or heavier enterprise products (like Microsoft SharePoint). But Atlassian found a sweet spot: a proprietary solution that was easier to try, cheaper to adopt, and still robust enough for serious enterprise needs.

Jira and Confluence: The Bedrock of Collaboration

Anyone who’s used Jira knows how quickly it can evolve from a simple ticketing system into a multi-layered project management engine. My old team primarily used it for firefighting (reporting critical incidents, linking them to infrastructure changes, and building out runbooks). But it could just as easily track marketing tasks, sprint boards, or product roadmaps.

Confluence, on the other hand, tackled the “knowledge management” side of the equation. Instead of storing docs in email attachments or random Dropbox folders, you’d toss them into Confluence spaces. I remember first encountering Confluence at a large organization: entire runbooks, architectural diagrams, and how-to guides all lived in one place. Even though it sometimes felt a bit unwieldy, it was undeniably powerful as a central hub of knowledge.

That synergy - Jira for tasks and tickets, Confluence for team wiki-collaboration - became the bedrock for Atlassian’s early dominance. Their go-to-market model was also refreshingly simple: you’d sign up, download, or deploy it on your servers, and Atlassian would charge per user license. No big, expensive pitch. No dozens of calls with a sales rep. Just try it, buy it, and expand as needed.

Bitbucket Enters the Picture

By the late 2000s, version control systems were undergoing huge changes. GitHub had begun to capture developers’ hearts and minds, showing that a hosted Git service could become a central hub for collaboration. Atlassian, recognizing that Git was the next big wave, acquired Bitbucket in 2010. Bitbucket at the time was smaller and focused on Mercurial. But as Git’s popularity soared, Bitbucket added full Git support, and eventually (by 2020) dropped Mercurial altogether.

Facinating to me that BitBucket originally only supported Mercurial

Nowadays, Bitbucket is heavily intertwined with Jira. You can open a ticket in Jira, link it to a pull request in Bitbucket, and get your entire code review and deployment pipeline managed under Atlassian’s broader ecosystem. In contrast, GitHub merges issues and pull requests in a single ID space, effectively blending project management directly into the code platform. Bitbucket took a more integrated, “ticket-first” approach. If you’re already paying for Jira, you might figure, “Why not just add Bitbucket, too?” Over time, that synergy led a lot of companies to adopt the Atlassian toolchain end to end.

One interesting difference: Bitbucket was faster than GitHub to add certain DevOps features (CI/CD) and to offer on-premises options (Bitbucket Data Center). So for large enterprises needing self-hosted solutions, Atlassian often became the logical choice.

Competing in a Changing Landscape

By the mid-2010s, Atlassian had established itself as the serious enterprise alternative to the more developer-community-centric GitHub. They even launched or acquired tools like Trello (for Kanban-style project management), Opsgenie (for incident response), and Stride/HipChat (for team chat) in an effort to build a one-stop shop for business collaboration.

But the new wave of competition started looking different. You had lighter, more design-centric tools like Linear, which showed that project tracking doesn’t have to feel so heavy. Meanwhile, Slack devoured HipChat’s share of the messaging space. In fact, Atlassian ultimately sold HipChat to Slack rather than try to compete further - a decision that felt like a rare misstep for them. And with the massive growth of GitHub, which had a friendlier brand for open source and small teams, Atlassian’s “all-in-one” approach sometimes felt more geared toward big companies with dedicated procurement processes.

As developer workflows became more modular, many teams began picking best-in-class solutions and stitching them together via standard APIs. You might choose Notion for docs, GitHub for version control, Slack for chat, and a new upstart like ClickUp or Linear for tickets. Ten years ago, integrating all these separate tools was painful; you’d need custom scripts or unwieldy APIs. Now, it’s far more seamless, eroding some of Atlassian’s biggest advantage in having an integrated suite.

Innovating (or Risking Obsolescence?)

That begs the question: is Atlassian doomed to become a “legacy player” - the same role it once cast its predecessors in? Possibly. But there are good reasons to think they’ll could stick around.

1. Enterprise Loyalty: Major corporations continue renewing Atlassian licenses year after year. And once a giant company’s entire ticketing and docs system is entrenched, switching away is non-trivial. The cost of migration can be scary, especially if there are thousands of employees who need retraining.

2. Massive Data Vault: Atlassian houses an incredible amount of data - tickets, wikis, PR histories - for some of the world’s most influential companies. If Atlassian integrates AI-driven insights, automated ticket triage, or advanced analytics on top of that data, it could offer enormous value that’s hard for smaller vendors to match.

3. Product-Led DNA: The founders, Mike Cannon-Brookes and Scott Farquhar, have historically prioritized the product-first mentality. That’s how they built the business from scratch without a big sales org. If they can maintain that ethos, even at Atlassian’s size, they might keep delivering the right features at the right time.

On the flip side, new startups with ultra-modern UX, specialized features, and flexible integrations might pull younger companies away from Atlassian’s ecosystem entirely. The question: can Atlassian release fresh tools quickly enough to stay ahead of that wave?

Looking Ahead

From my vantage point, Atlassian’s next decade will hinge on whether it can adapt quickly. The boat was arguably missed with HipChat, but AI-driven collaboration and advanced knowledge management might be Atlassian’s next big frontier. Imagine a world where Jira automates your ticket updates, Confluence pre-writes your project specs, and Bitbucket uses machine learning to review your code or highlight potential issues. That’s a compelling future - if they can implement it smoothly and keep pace with smaller startups iterating at lightning speed.

For Atlassian’s part, they already have Rovo and other AI initiatives that hint at more advanced capabilities. They also have Atlassian Ventures, a fund investing in startups that complement or extend the Atlassian ecosystem. Perhaps that’ll help them tap fresh ideas and remain flexible amid a changing tech landscape.

Despite its enormous presence, Atlassian didn’t define most of my own day-to-day workflow. But I can’t ignore the huge role they play for large enterprises around the globe, or the captivating journey they took - from a $10,000 credit card bet to a publicly traded juggernaut. No matter what the future holds, it’s hard not to respect the founders for that initial leap and the self-serve model that made Jira and Confluence so ubiquitous.

Whether Atlassian will reinvent itself to stay a top choice for modern dev teams - or fade into the background as “legacy software” - is anyone’s guess. But if history is any guide, they have a knack for surprising the market. As software collaboration continues to evolve, I’m fascinated to see what Atlassian does next.

Citations & Further Reading

• Atlassian - History Timelines

• Bitbucket on Wikipedia

• Thought Economics: Scott Farquhar Interview

• Atlassian Founders on 20 Things They’ve Learned in 20 Years

• Deep Dive into the Characters and Values of Mike Cannon-Brookes and Scott Farquhar

Several apps are already lining up to integrate. Notion, Warp, and others are embracing this evolution. Older, more entrenched platforms - like Microsoft Office - may initially resist. But how long can they hold out when interoperability comes through a consistent, standardized API rather than a proprietary plugin? As momentum builds, reluctance will be harder to justify.

OpenAI’s team has hinted that this is just the beginning. Instead of users copying and pasting between windows, future iterations might integrate even more fluidly with your workflow. Consider what it means for knowledge work: Grammarly already suggests in-line edits and improvements without requiring us to hop between tools. Why shouldn’t our AI assistants do the same, not just for grammar or formatting, but for end-to-end creation, editing, and integration of all types of content, including code?

What Does This Mean for Development Tools?

Engineering, historically, is a text-based discipline. Sure, we have GUIs for configuring cloud services and dashboards for DNS management, but the trend has always swung back to “config-as-code.” We articulate our systems through text files - YAML configs, Terraform scripts, Dockerfiles - and store them in code repositories. As AI models become more capable, three distinct patterns are emerging:

1. Smarter Autocompletion in Existing Editors

Tools like VSCode, Cursor, and Windsurf offer contextual suggestions. This first wave is intelligence grafted onto the editor experience, making coding faster and less error-prone but still anchored in the traditional environment of text editing.

2. Headless Code Generation

A second trend is emerging where code changes skip the editor entirely. Tools like Google’s experimental Jules, Cognition’s Devin, and platforms like Factory.ai aim to commit meaningful code changes directly to repositories. This bypasses the local editor and introduces a more autonomous, AI-driven approach to code creation.

3. A Unified Interface Layer on Top of “Dumb” Editors

Now ChatGPT hints at a third path: an interface layer that can read and write to applications directly through something like an accessibility API. Instead of relying on editor-specific extensions, ChatGPT might present a universal interaction layer that orchestrates multiple tools. It could act as an intelligent “bridge” between you and a variety of applications - none of which need to be made “smart” themselves.

If we consider these paths, which is most likely to dominate? If the contest were only between the first two paradigms - smart autocompletion within editors versus headless code generation - headless would eventually win. Why? Because real engineering teams aren’t just pairs of programmers making small suggestions in one another’s IDEs. They’re networks of autonomous, capable individuals who propose high-level architectural changes, iterate on significant refactors, and collaborate through code review processes rather than line-by-line autocompletion. As soon as AI models become just “smart enough,” human-level interactions with code will transition from typing in editors to guiding AI agents to produce fully formed changes directly in repositories.

Rethinking the Interface of Collaboration

This raises an important question: where do we guide these AI agents? Before, it seemed natural that prompting would occur within GitHub’s interface (or any other system of record) - after all, GitHub is where we host, review, and merge code. It has maximum context and doesn’t need a sophisticated editor UI in an agentic world. But OpenAI’s demonstration suggests another possibility: a unified workspace like ChatGPT itself could become the place where prompts are given. Why browse GitHub when the AI interface can read from GitHub, write to it, and ultimately manage the entire creation?

Imagine prompting ChatGPT: “Create a new PR that adds feature X.” With deeper GitHub integration, ChatGPT could read codebase context, spin up a new branch, write the code, push it, and open a pull request - without ever leaving the ChatGPT window. The human developer’s job shifts from typing code to supervising AI-driven tasks, guiding architectural decisions, and ensuring strategic alignment. Copy-and-paste dissolves, replaced by a frictionless “everything” interface. GitHub becomes reduced to a system of record and pipes, and its custom-build interface begins melting.

A New Model of Creation

As these AI-driven interactions expand, we might see a gradual dissolution of traditional editor boundaries. Notion for docs, Figma for designs, and VSCode for code might still exist as data sources and specialized back-ends, but the creation interface may unify into a universal “front end” like ChatGPT. AI will act as the translator and integrator, pulling context from Notion pages, committing code changes directly into GitHub, or exporting design frames to a Figma file - all initiated by commands in a single interface.

In this scenario, the differentiated value of each platform becomes the mechanical systems they provide - CI/CD pipelines, merge queues, or high-performance data synchronization - rather than their role as primary user interfaces. The specialized apps remain essential for integration, storage, performance, and compliance, but the user’s day-to-day creation and editing could shift to a single, AI-driven surface.

Who Loses, Who Wins?

Traditional editor apps might risk becoming “headless back-ends” for AI agents. Instead of navigating multiple tools, users could use ChatGPT as the main interaction point. The winners will be pipes-based tools that provide value storing, moving, and computing data. The losers are the per-seat tools, those that pride themselves on niche, custom-built editing UIs.

Side note - accessibility pattern users also stand to be huge short-term winners. This may lead to the largest up-pri of screenreader API adoption ever seen.

Ultimately, the shift is toward a universal creation interface - an “everything-editor” - powered by AI. As intelligence becomes commoditized, convenience and frictionless integration matter most. Content, code, and data all flow through a unified channel. The future could be one where the lines between tool, assistant, and environment blur, and where the “app” you interact with is less important than the intelligence and integration that the app enables.

There was once a fifth value: “Simplify,” which ironically vanished over time, simplifying itself right out of existence. That always made me sad - simplify was perhaps the best value because it was, well, simple and actionable.

Airbnb’s values were clever, sure, but I always had to look them up to remember them. Even having worked there for years, I could only consistently recall “Be a Host.”

This isn’t to pick on Airbnb; they’re just my most salient point of reference. The challenge with so many company values, especially in the early days, is that they’re aspirational to a fault. Often, they’re meticulously worded, on-brand, and uplifting - but not always directly actionable. How do you decide whether to reduce AWS costs or over-provision your database for stability by referring back to “Embrace the Adventure”? These principles can feel too vague to settle real-world tradeoffs. You end up with either overly broad platitudes or niche specifics that no one remembers.

When we started Graphite, we tried to articulate a set of values we wanted to embody. We came up with something like this:

1. Work in Pencil

   1. We constantly edit and improve everything we build.

   2. Expect your work to be changed or erased as we grow.

2. Mine, Cut, and Polish

   1. Start by testing many ideas to discover what resonates.

   2. Refine and reduce to only what’s most valuable.

   3. Polish until the result is stunning.

3. Exercise Empathy

   1. Understand what matters to users and teammates.

   2. Treat everyone with kindness, honesty, and respect.

4. Play Like a Championship Team

   1. We’re a team, not a family.

   2. Align ambitions with the team’s goals.

   3. When we succeed, we celebrate together.

We spent hours debating and refining these statements. The hardest part was wrestling with hypothetical situations: How should we weigh quality versus prototyping speed? When should we push for polish versus good-enough solutions? These theoretical tradeoffs led to endless discussions. The result, while thoughtful, sometimes felt too aspirational - more like predictions of who we hoped to be than reflections of who we actually were. And just like Airbnb’s values, the the team struggles to rattle them off - they’re simply hard to remember.

Over time, I’ve come to believe that early on, you shouldn’t waste much time trying to nail down company values. In the beginning, what you need is traction - forward motion that tells you what actually matters. Only after you’ve faced repeated challenges and made hard decisions do certain truths emerge as genuinely core. Values should be an uncontentious record of battles won and lessons learned, not a wishlist for who you might become someday.

At Graphite, I’ve found myself organically settling on three simple words that capture what we, the team, live and breathe every day:

Kindness, Expertise, and Urgency.

That’s it. Three words, easy to remember, and perfectly aligned with who we’ve become. When candidates ask about our values, I say these three words. They’re uncontentious internally, and they reflect attributes we’ve seen proven crucial, time and again. If someone doesn’t embody all three, it shows quickly. These values help us hire the right people and, if necessary, let go of those who aren’t a fit.

Kindness

We’re an in-person company, working together under high pressure, iterating at the whiteboard, debating product direction, and building for world-class engineering teams. Half our job is building the company itself - collaborating, communicating, and leading. Without kindness, this environment becomes intolerable. We need people who are supportive, who turn tense moments into opportunities for understanding, who help others feel safe to contribute. Without kindness, the whole thing falls apart.

Expertise

We’re not just building a product; we’re building an opinionated tool that tells world-class engineers - at places like Vercel, Datadog, and Snowflake - how they should shape their development workflows. That’s a bold stance. You can’t convincingly do that unless you know your craft inside and out. Expertise is non-negotiable. If you’re going to guide top-tier engineering teams, you need to be at their level - or pushing beyond it.

Urgency

Our mission is to help engineers ship code faster. We exist to accelerate software development. We’re also a startup, and speed is one of our greatest advantages. We’re not advocating recklessness, but we do believe in moving quickly, trimming unnecessary steps, and pushing out iterations to learn faster. If something’s blocking progress, we resolve it immediately. We ask: “What can we do right now to move one step closer to our goal?” Move fast, stay nimble, stay alive.

“Startups are like sharks. If they stop swimming they die.”

Evolving Values Over Time

What’s beautiful about these values - kind, expert, urgency - is that they emerged naturally over time. I didn’t force them into existence. After two years of growth, iteration, and facing real-world challenges, these words feel obvious, almost inevitable. They reflect the core of who we are and what we need. They’re easy to remember, easy to explain, and easy to uphold.

Will our values change again as we learn more, evolve, and grow? Possibly. Probably. Values should be living, reflective documents, not stone tablets. Today, these three principles describe our lived culture. And if a few years from now, we learn new lessons that push us to re-articulate our values again, we’ll update our values again to accurately describe the energy in the room.

TL;DR: Yes, we ship code fast - at a pace that’s unusual even by top-tier engineering standards. But more importantly, we do it by embracing a workflow that minimizes the waiting game, encourages thoughtful iteration, and makes the most of our tools.

Why Discussing Speed Is Tricky

Engineering productivity is a sensitive topic. On the surface, it sounds simple - ship more code, faster. In reality, it’s not that straightforward. Different products and teams have vastly different requirements, from complex regulatory hurdles to intricate performance constraints. Metrics like lines of code or hours in the office rarely capture the true nuance. Every experienced engineer knows that “butts in seats” or “hours worked” is a poor proxy for real productivity. Quality matters. Thoughtfulness matters. Maintenance and reliability matter. And yet, we keep coming back to the same question: “Is your engineering team fast?”

At Graphite, I get asked this question a lot - by investors, customers, potential hires, and even peers at other companies. Some form of the question inevitably pops up: “Are you pushing the team hard enough?” or “I’ve heard of companies that pull all-nighters - are you doing that?” Sometimes, it’s simply: “You build productivity tools, so you must be insanely productive yourselves, right?”

These questions don’t come from a bad place. They come from curiosity and the desire to understand what “fast” looks like. They also come from a world where, historically, productivity has been measured in the wrong ways. That said, if you’re on the outside looking in, it can be perplexing. Our team is well-compensated, well-supported, and trusted to work their own hours - yet we don’t subscribe to the “always on” hustle, nor do we push for grinding 20-hour days. How, then, do we show that we are indeed moving at an exceptional pace?

Measuring Code Change Velocity

If there’s one thing Graphite knows, it’s how to measure the flow of code. After all, one of our core offerings is built around managing and tracking pull requests.

So I’ve decided to let the data speak for itself. Below are some metrics collected over a recent quarter (Q4 2024) for our 9-person engineering team. I compared them against industry-wide benchmarks (based on aggregate data from GitHub repositories of all shapes and sizes):

• Number of Pull Requests per Engineer per Quarter (Median):

  • Industry median: 33 PRs per engineer

  • Graphite median: 324 PRs per engineer

• Number of Pull Requests per Engineer per Quarter (P90):

  • Industry P90: 114 PRs per engineer

  • Graphite: 489 PRs per engineer

• Median Lines Changed per PR:

  • Industry median: 36 lines

  • Graphite median: 34 lines

• Median Time to Merge (from PR open to merge):

  • Industry median: 2.7 hours

  • Graphite median: 5.7 hours

The takeaway? Graphite’s engineering team is in the 99th percentile and beyond when it comes to throughput measured by merged PRs. Our changes aren’t abnormally small, and our time-to-merge is actually a bit slower than average. Yet, we produce far more merged PRs per engineer than typical teams.

At first blush, that might seem contradictory. If we merge more slowly, how are we shipping more code? The key lies in how we structure our work.

The Secret Sauce: Stacked PRs and Parallelized Work

A defining principle of our development process is the use of stacked PRs, a core concept we champion. Traditionally, waiting for a PR to merge before moving on to the next related change can act as a bottleneck. By stacking PRs, we break down large changes into a series of smaller, reviewable increments. Each increment can be developed, reviewed, and tested concurrently. Instead of waiting idly for one PR to merge, engineers can continue building the next layer of functionality.

This approach naturally leads to a higher total count of PRs - each one is smaller and more focused. It also means that a single PR might wait in the queue a bit longer (hence the slightly increased median time-to-merge), but the overall flow of code doesn’t stall. Engineers are never blocked; they always have another PR to work on. As a result, the entire chain of features moves forward in parallel, and a steady, healthy drumbeat of merged PRs follows.

This method directly reflects the philosophy behind Graphite’s tooling. Our product encourages an iterative, parallelized workflow that maximizes efficiency without sacrificing code quality. We eat our own dog food, and it’s working.

Perspective and Caution

Now, none of this is to say that shipping a large number of PRs is the only metric that matters. Teams vary widely in their domains, skill sets, and constraints. Some products need more rigor and longer review cycles due to the criticality of their software - think medical devices or financial platforms. Others might have less internal tooling or different cultural norms around code review. Simply aiming to be “faster” without understanding your product’s unique context can lead to burnout or dropped quality standards.

I share these metrics and our workflow not to brag, but to inspire. If you’re a leader frequently asked about your team’s productivity, let these numbers serve as one data point. If you’re an IC engineer who knows how nuanced productivity truly is, consider this a case study of how process and tooling can unlock surprising speed. And if you’re evaluating Graphite itself - either as a prospective employee, customer, or curious observer - know that we’re not only building productivity tools, we’re proving they work.

A Small Team with Remarkable Pace

It’s fair to be skeptical of any claims about “incredible speed” in engineering teams. The industry has a long history of measuring the wrong things and glorifying overwork. I hope to show a different story: a small team shipping at a remarkable pace, not because we’re pulling constant all-nighters, but because we’re leveraging parallel workflows, trusting each other, and using our own tools to minimize friction.

Is Graphite’s engineering team fast? The data suggests we are, by a wide margin. More importantly, we’ve found a model that consistently lets us iterate quickly, maintain quality, and stay sane. I believe others can learn from this, adapt it to their own contexts, and ultimately deliver value to their users at a pace that might just surprise them.

At the same time, I’m watching with a mix of excitement and caution as a new trend emerges: AI-generated pull requests. Several companies are racing to build “self-driving PRs,” where autonomous systems read your entire codebase, understand outstanding tasks, and start submitting their own PRs - like tireless open-source contributors who never sleep and never lose focus. In theory, this could dramatically reduce the manual time developers spend writing boilerplate code, hunting down bugs, or implementing repetitive features.

What intrigues me is how these two trends - stacked PRs and AI-generated PRs - might intersect. How does the workflow of tomorrow look when we blend the human pattern of stacking with the robotic efficiency of machine-generated pull requests?

Why Smaller PRs Are Better

It’s widely accepted that small, focused PRs are the gold standard. They’re easier to review, catch fewer bugs, and integrate into production faster. Small PRs also reduce the risk of massive conflicts and make rollbacks painless when something unexpected happens in production.

The challenge with small PRs is the overhead. After creating one, you typically wait: wait for continuous integration (CI) checks, wait for a code review, and then wait for a merge queue. If you worked linearly, you’d be stuck twiddling your thumbs every time you push a small change. That’s where stacking comes in. Instead of waiting around, you branch off an unmerged PR and keep going. You move in parallel with the review and CI cycles, accelerating your iteration without bloating the scope of any single PR.

This is incredibly liberating for teams that value speed. It creates a virtuous cycle: small PRs remain small because you never feel the need to stuff a bunch of extra changes in just to stay busy. Instead, you rely on stacking to keep moving forward, adding small increments of value to the codebase in quick succession.

Collaboration Through Stacks

Stacking also makes collaborative development more natural. Instead of two engineers editing the same file in real time - potentially creating confusion or conflicts - they coordinate through a chain of PRs. For example, one engineer might introduce a new API endpoint in the first PR, while another stacks a second PR that integrates it into the frontend. The result is a neat, linear sequence of changes that makes it easy to understand the evolution of the feature, roll back if needed, and track down when a particular bug was introduced.

A Perfect Match for AI-Generated PRs

Now, consider AI-driven systems slotting into this workflow. The advantages that humans gain from small, stacked PRs would matter even more to AI. If an AI model can propose a tiny improvement - a refactoring here, a style tweak there - it can do so rapidly and repeatedly. It won’t get bored or frustrated by waiting on feedback loops; it will just move on to the next incremental improvement.

But to maintain those rapid-fire cycles, you don’t want the AI sitting idle, waiting for PR #1 to get merged before starting on PR #2. As AI brings coding time to zero, validation steps become a bigger bottleneck. If you’re going to have an AI agent writing code continuously, it makes perfect sense to let it stack PRs on top of each other. While the first PR waits for CI and human review, the AI can already be working on the next unit of value. This parallelization aligns perfectly with the AI’s unending capacity for work.

In the same way that humans collaborate through stacks, AI can collaborate with humans - or even with other AI models - in a stacked environment. One model might be great at quickly drafting a new UI component, while another model specializes in performance optimizations. A human can start the chain, the AI can pick it up and continue, and another model (or a human) can finish the refinement. This layered approach lets everyone - human or machine - contribute within a structure that remains clear and incremental.

The Future: Agentic, Modular, and Fast

All engineering processes improve when we modularize, create dependency graphs, and parallelize work. Code changes are no exception. Stacked PRs provide a natural way to apply these principles to software development, and as we move toward a future of agentic, AI-driven code generation, the importance of stacking only grows.

Rather than viewing self-driving PRs as a separate paradigm, I see them as a natural extension of what we’re already doing: making PRs smaller, faster, and more collaborative. The synergy between stacked PRs and AI-generated PRs will define the cutting edge of software delivery - leading to codebases that evolve continuously, effortlessly, and intelligently.

In a world where code can be written at any time, from anywhere (including by non-human agents), the need to organize, structure, and control that flow of changes becomes paramount. Stacked PRs provide that structure. AI-generated PRs bring the raw horsepower. Together, they create a future where software development is both high-velocity and reliably stable - exactly the kind of environment we should be building toward.

At first glance, each offering seems well-tuned to its native platform. Amazon Q Developer, trained on AWS’s own 17-year corpus of service knowledge, focuses on tying code and infrastructure together, helping developers understand and manipulate AWS resources directly from the console or IDE. GitLab Duo, by contrast, extends GitLab’s repository management, CI/CD, and security scanning capabilities with AI - streamlining code suggestions, vulnerability explanations, test generation, and even pipeline failure root-cause analysis.

Yet, these new tools land in a world already saturated with AI developer assistants. GitHub Copilot, ChatGPT-based integrations, Codeium, Cursor, and a host of smaller players have been delivering smart code completions, test generation, and security suggestions for over a year. The question, then, is whether Amazon Q Developer and GitLab Duo offer something uniquely valuable - or are simply late entries in a game that’s already advanced.

What Amazon Q Developer Offers

Amazon Q Developer’s pitch is that it isn’t just another general-purpose coding assistant. It’s an AWS expert. Key capabilities include:

• AWS Infrastructure Awareness: Q can list and describe AWS resources, navigate the console, and generate AWS CLI commands. A developer can say, “List all of my Lambda functions in Singapore,” and Q returns not just code suggestions, but direct links and CLI instructions. Q also helps with cost exploration, summarizing which AWS services drive spending and linking directly into Cost Explorer for validation.

• Code Transformation and IDE Integration: Q can assist with code upgrades - like migrating Java projects to newer versions - right from within JetBrains IntelliJ IDEA or VS Code. It can also generate development plans and test code in real time. All this happens under the AWS umbrella, leaning on secure sign-ins and Builder IDs.

The unique angle is that Q attempts to move beyond generic coding help by integrating operational and financial insights. Instead of fumbling through multiple AWS dashboards, a developer can query infrastructure and costs in natural language. By doing so, Q aims to position itself as a single point of AI-enabled navigation across the AWS stack.

What GitLab Duo Promises

GitLab Duo takes a different path. It’s not just a code editor assistant, though it does offer the familiar code completions and test generation. Instead, its capabilities span:

• IDE and CLI Integration: Smart completions, chat-based refactoring, test generation, and explanation of code directly in your IDE.

• CI/CD Troubleshooting: Automated root-cause analysis of pipeline failures, with suggestions for remediation - a clear nod to GitLab’s existing strength in CI/CD.

• Security and Compliance: Explanations of vulnerabilities, along with auto-generated merge requests to fix them. By integrating directly into the commit-to-deploy pipeline, Duo promises developers can address security issues before they hit production.

• Summaries and Templating: Merge request summaries, issue and epic explanations, and a “conversation” layer that can parse GitLab’s entire project history.

GitLab Duo’s differentiator is its promise to provide AI assistance at every stage of DevSecOps, not just coding. It’s about tying all project artifacts - issues, epics, merges, tests, security scans - into a single, AI-interpreted narrative that helps teams ship more secure software, faster.

A Crowded World Already Full of AI Assistants

If I isolate the feature lists - code suggestions, chat-style Q&A, summarization, test generation, command recall - these capabilities are table stakes in late 2024. Smaller, more agile vendors have been pushing this frontier for a while. The brute functionality of generative AI coding is no longer an innovation. The novelty has worn off.

What Amazon Q and GitLab Duo have going for them is their native integration into enterprise ecosystems. While independent developers can easily install Cursor or Codeium, large enterprises often prefer a sanctioned, vendor-backed solution. GitLab and AWS each have substantial footholds in large organizations. Many Fortune 500 companies already rely on AWS infrastructure and GitLab’s pipelines, and are eager for AI solutions blessed by their existing security and compliance frameworks.

In short, these new offerings might not lure the AI-savvy solo developer, who can mix and match tools as they please. But the CIO of a major enterprise might be far more comfortable adopting Q and Duo organization-wide, ensuring uniform compliance, data privacy, and consolidated billing. Here, the “innovation” is more about distribution and procurement than technical features.

Still Missing a Killer Differentiator

Despite these advantages, there’s a lingering sense that Amazon Q and GitLab Duo could do more. Amazon Q, for example, knows your AWS configuration and cost structure. Why not turn that into proactive guidance? Q could, theoretically, identify underutilized EC2 instances and suggest infrastructure-as-code changes, then automatically generate and test those changes before deployment. Instead of merely listing resources or running transformations on request, Q could become a continuously improving co-pilot of your cloud architecture.

Similarly, GitLab Duo could take code review summaries and vulnerability scans a step further. Why not have Duo actively propose architectural improvements or pipeline optimizations that only make sense given the entire organization’s codebase and historical CI/CD data? It could provide dynamic guardrails or even self-healing pipelines based on learned best practices gleaned from the enterprise’s own repository history.

These types of “multiplay” features - scenarios that only make sense when integrated deeply into the entire stack - are what could truly differentiate these native tools from generic LLM-based assistants. The potential is enormous. Both Amazon and GitLab sit atop vast troves of system-level knowledge, infrastructure data, and historical code patterns. If they harness that vantage point, AI can do more than just autocomplete code - it can reshape the process of building and running software in ways smaller competitors cannot.

Enterprise Distribution is Not Enough

Amazon Q and GitLab Duo arrive late to a crowded party. On pure functionality, they’re no more compelling than what developers have had access to for over a year. But timing is not everything; their advantage lies in their position within large enterprise ecosystems, where trust, compliance, and existing contracts matter a great deal.

That said, the current feature sets - fancy as they appear - remain incremental. Long-term success will require delivering capabilities that justify enterprise-wide adoption: proactive infrastructure optimization, integrated compliance and cost management, security-first development workflows that transcend single-player coding sessions.

Right now, these offerings feel like safer, top-down versions of AI tools everyone already knows. The path to real differentiation runs through leveraging each platform’s unique organizational data and capabilities. If Amazon Q and GitLab Duo focus on that path, they might yet redefine how enterprise developers build, secure, and manage software. If they don’t, they risk becoming just another check-the-box feature in an already crowded landscape.