Bryan Helmkamp and the trouble with good code

Bryan Helmkamp’s first version of Code Climate counted lines of code and plotted them over time. It had the pleasures of a respectable dashboard: numbers, movement, a picture of something happening. By his own account, it was pretty and offered little practical help. A graph can tell you that your software is getting larger. It cannot, by itself, tell you what to do on Monday.

That small disappointment makes a useful opening to his career. Helmkamp has spent years building tools that examine software, and just as much time explaining how people should use the results. The recurring problem is the distance between knowing something and acting on it. A developer sees a warning. A manager sees a delay. A board sees a number. Each needs enough context to make a sensible next move.

Today he is the co-founder and CEO of Qlty Software, the company that emerged from Code Climate’s Quality product in 2024. The work has acquired new languages, new customers and, lately, AI-generated code. The question beneath it remains recognizably ordinary: how do you help people improve a working system without making their working day more difficult?

Before the dashboard, a shared vocabulary

By 2008, Helmkamp was a senior Rails engineer at weplay in New York and an active participant in the RSpec community. He had released Webrat, an acceptance-testing tool for web applications. He also helped organize Rails Day 2007 and the Gotham Ruby Conference. His involvement included the unglamorous labor of making a community happen, alongside the more visible labor of speaking to it.

His 2008 GORUCO talk concerned story-driven development. The appeal was that product owners and developers could describe expected behavior in a common language, then make those descriptions executable. A requirement could become a test that continued to check the application. The next change would have something more useful to consult than a document growing elderly in a folder.

He later co-authored The RSpec Book with David Chelimsky, Dave Astels, Zach Dennis, Aslak Hellesøy and Dan North. Its subject, behavior-driven development, brought design, documentation and testing into the same conversation. The authorship fits a career in which explaining the work has repeatedly accompanied doing it. Software can be precise while the conversation around it remains wonderfully vague. Tests offer one way to bring the two closer.

A Ruby Hero Award followed in 2009. Helmkamp’s earlier career also included engineering at Gilt Groupe and the CTO role at Efficiency 2.0. Those jobs placed him inside actual software businesses, where an application has to survive changing demands. It is easy to admire clean code in a demonstration. Maintaining it while the business keeps moving supplies a rather sterner examination.

A company begins with a question

The first Code Climate commit was dated March 6, 2011. Helmkamp had seen capable teams struggle to keep large Rails applications maintainable. They used established practices, including pair programming, yet the problem persisted. Static analysis - examining code without running the application - looked like another source of help, if someone could make its findings convenient enough to use.

He tested the idea with mockups and conversations in the Ruby community, including at conferences, and a survey distributed through Twitter. One early possibility was a weekly email describing changes to a codebase. By March 2012 he had left his full-time job to work on the bootstrapped business. The path was a succession of specific questions and feedback, rather than a fully furnished vision arriving on day one.

Code Climate eventually translated analysis into familiar A-to-F ratings for classes and modules. Yet Helmkamp cautioned against making every result an assignment. He did not advise customers to chase a report full of A grades. A tool that identifies opportunities still needs a person to decide which opportunities deserve attention. Otherwise, the software meant to reduce work becomes an exceptionally organized supplier of more work.

“I’m a Rubyist at heart”

Bryan Helmkamp, 2012

The metric must earn its place

At GORUCO in 2016, Helmkamp returned as a keynote speaker. He had attended every edition to that point, and joked about the practical drawback of the honor: speaking first thing in the morning. Years of community involvement had brought him back to a familiar room, this time with lessons gathered from running a code-analysis company.

One lesson was disarmingly plain. When a team is trying to understand complexity, a measurement it understands can be more useful than one it has to debate. His talk compared sophisticated formulas with something nearly everyone recognizes: the size of a method or class. A sprawling file offers a concrete starting point for a conversation about dividing responsibilities.

He also made room for imperfect code when the circumstances justified it, including experiments intended to test a hypothesis or code destined to be discarded. The position complicates any cartoon of a quality-software founder as a stern examiner with a red pen. Commercial software involves judgment. There are moments when learning whether an idea matters should come before polishing every line used to try it.

In a separate 2016 presentation, Code Quality in Practice, he addressed what makes a metric valuable and why maintaining quality remains difficult. The wider lesson is that a measurement needs a job. Precision has little practical value when nobody can connect it to a decision. For a company selling analysis, that is a useful discipline: the customer’s next action matters more than the elegance of the instrument.

When the code became a company-sized question

Code Climate launched Velocity in 2018, extending the company’s attention from code itself to the people and processes involved in delivering it. Helmkamp also authored The Engineering Leader’s Guide to Cycle Time. The unit of concern had widened. A particular method might be difficult to maintain; an entire organization might be difficult to coordinate.

In a 2020 panel with Kathryn Koehler and Smruti Patel, moderated by Juan Pablo Buriticá, Helmkamp described velocity in terms of moving quickly in the right direction, with alignment and efficiency. He distinguished goals from metrics and argued for balanced measurements. Counting movement is easy. Establishing whether the movement helps the organization requires another conversation.

That distinction has consequences for leadership. A target can make a team concentrate on improving a number while neglecting the reason the number was collected. His emphasis on cycle time points toward the passage of work through a system, inviting questions about where it waits and what prevents it from moving. It gives a leader somewhere to investigate, rather than merely someone to congratulate or scold.

By 2021, his own company had moved from a largely co-located New York team to a fully remote one, with headcount more than doubling during that transition. He described recruiting and onboarding leaders, clarifying objectives through OKRs, and reconsidering which communication belonged in meetings and which in written updates. The analyst of engineering systems had an organizational system of his own to maintain.

His approach to planning started with an empty calendar. Instead of shaving minutes from an inherited routine, he asked what would deserve to be added if the schedule were cleared. It is a practical thought experiment with an uncomfortable implication for recurring meetings: longevity offers no guarantee of usefulness. A calendar, like a codebase, can collect decisions whose original reasons have quietly disappeared.

In later discussions about reporting to executives and boards, he continued to emphasize intelligible evidence. He appeared with Sha Ma in a 2022 panel moderated by Pooja Brown about communicating engineering’s impact. A technical organization must explain itself to people who do not share its daily vocabulary. That task echoes the early interest in readable requirements, although the audience now sits much farther from the editor.

“if you imagine clearing your calendar entirely, what would you add to it?”

Bryan Helmkamp, 2021

Quality gets its own address

In November 2024, Code Climate announced that its Quality product was becoming a separate company, Qlty Software, while Code Climate concentrated on Velocity. The announcement described two products serving different kinds of engineering organizations. Separating them gave each business a clearer focus. For Helmkamp, Qlty renewed his attention to the code-maintenance problem at the beginning of the story.

His December introduction framed Qlty’s mission around removing toil from software maintenance. The initial CLI offered linting, automatic formatting and code metrics across multiple languages, with support for macOS, Linux and Windows. A command-line tool meets developers where they already work. It also has to justify the time it takes every time someone runs it.

In February 2025, Helmkamp explained the choice of Rust for that CLI: performance, reliability, static typing and straightforward distribution as self-contained binaries. Most of the team had been learning Rust while building the tool. It was a pragmatic choice for a founder long associated with Ruby. Familiarity with one language need not become a lifetime contract to use it for everything.

Licensing supplied another deliberate tradeoff. Qlty published the CLI’s code and chose Fair Source, using Business Source License 1.1 with delayed publication under the GPL. Helmkamp described access and commercial sustainability as priorities. The choice made its terms part of the product’s story: developers could inspect the code, while the business retained restrictions intended to support continued investment.

His April writing returned to a smaller, recognizable nuisance: the red X on a failed continuous-integration check. A log full of findings can leave developers searching for the issue relevant to their change. Qlty’s approach emphasized consistent local and cloud checks, feedback inside GitHub, and attention to newly introduced issues. The concern is almost editorial: make the important finding visible; spare the reader the excavation.

More code, the same obligation

AI coding tools have given that concern fresh urgency. In April 2025, Helmkamp argued that verification was becoming the constraint as generating code became easier. He recommended established checks - linters, formatters and security scanners - before human review. He also warned that using AI to review AI-written code could leave shared blind spots in place.

The argument assigns automation a defined responsibility. Routine checks can remove routine problems, leaving reviewers more attention for behavior, architecture and context. Faster production of code does not make those questions disappear. It delivers them to the review queue sooner, occasionally with very confident formatting.

In September 2026, Qlty released SlopOne as a free research preview. The company described a hybrid approach combining static-analysis statistics with decisions from Typesafe AI’s Jev model to assess maintainability. Its report also helps users prepare refactoring prompts for coding agents. The release extends the investigation into what automated analysis can understand and how its findings can lead to changes.

For Helmkamp, the continuity is more interesting than the new vocabulary. From executable requirements to code ratings, delivery metrics and AI-assisted maintenance, his work keeps returning to the person who has to make the next decision. A useful tool should leave that person better equipped. The first chart counted what was there. The career that followed has kept asking what should happen next.