Jeremy Freeman, Co-Founder and CTO of Allstacks – Interview Series

Jeremy Freeman, Co-Founder and CTO of Allstacks, is a software engineer, technology architect, and entrepreneur with a career spanning software development, hardware engineering, machine learning, and product innovation. Since co-founding Allstacks in 2017, he has led the architecture and development of the company’s core platform, helping transform software delivery management through predictive analytics and AI-driven forecasting. Prior to Allstacks, Freeman held leadership roles at Ravioli Labs and CertiRx, where he worked on software engineering, research, anti-counterfeiting technologies, and product development. Earlier in his career, he gained experience across startups, enterprise technology firms, and academia, including teaching web development at Wake Technical Community College. His technical background spans embedded systems, hardware design, large-scale software platforms, machine learning, and engineering leadership, giving him a unique perspective on building data-driven products that help organizations improve software delivery outcomes.

Allstacks is a software engineering intelligence and value stream management platform that helps organizations improve the predictability and efficiency of software development. The platform integrates data from tools used across the software development lifecycle, including project management, source control, and deployment systems, then applies AI and machine learning to identify risks, forecast delivery outcomes, and surface actionable insights. By providing engineering and product leaders with visibility into project health, team performance, and development trends, Allstacks enables organizations to make more informed decisions, reduce delivery uncertainty, and better align engineering efforts with business objectives. Its technology is designed to help companies move beyond intuition-driven planning by leveraging real-time operational data to improve software delivery performance and strategic execution.

You’ve had a unique journey from leading research and engineering teams applying machine learning to software development data to co-founding Allstacks in 2017. What specific gaps or recurring problems did you observe that ultimately pushed you to build the company?

When we started Allstacks, we spent a lot of time upfront doing customer discovery, and the pattern that emerged was consistent: company after company had enormous amounts of data and still no idea what was actually going on. Delivering software was unpredictable despite having some of the smartest people in the room. That problem hadn’t been solved.

What became clear pretty quickly was that this wasn’t a reporting problem or an integration problem. It was a relationship problem. To know whether something is at risk, you need to know how a work item connects to a branch, the branch connects to a PR, the PR connects to a sprint goal, and the sprint goal connects to a business initiative. That graph doesn’t exist by default anywhere in the standard toolchain. You have to build it. And building it well is fundamentally an inference problem, which is where the ML background became directly useful.

Our goal from the start wasn’t to make an individual developer faster on feature X. It was to make the entire organization better. How do you align engineering effort to business outcomes? How do you make engineering genuinely serve the business rather than just exist alongside it? You need a better understanding of the data relationships to answer those. It’s those questions that have driven almost every product decision we’ve made.

Allstacks focuses on analyzing data across the entire software development lifecycle. What types of signals or patterns are most predictive when it comes to identifying delivery risk early?

I don’t think there’s a single set of metrics that predicts good and bad, but rather patterns for different phases and types of organizations. What I’ve found more useful is recognizing that engineering organizations go through seasons of improvement. This month, it’s database performance. Next month, it’s cross-team communication. Then it’s “why can’t we close any PRs?” Then observability. As an engineering leader, you’re swimming in signals: some diagnostic, some monitoring, and a lot that’s just noise.

What helps is starting with the problem you’re actually seeing, not a metric you want to improve. If you’re asking “why does it feel like we’re delivering less than last year,” that’s the right starting point. From there, I think you need three types of metrics: first, how do you know the problem is real (maybe PR count per developer over time); second, what changes are you making and how are you tracking them along the way (say, adoption of an AI PR reviewer if that’s your intervention); and third, how significant is this problem to the business. Your instinct might be right that you’re shipping 20 percent less code, but the real story might be that QA is now taking three times longer. You need all three lenses to know whether you’re solving the right thing.

You’ve worked across industries like healthcare, energy, and technology. How do challenges in software delivery differ across these sectors, and how has that shaped the Allstacks platform?

I really value my experience in non-pure technology sectors. In SaaS companies, it’s easy to get lost in the idea that the software itself is the goal. When you’re in a business where you’re not directly selling the software, your role becomes a lot clearer: technology is there to support the business. I often joke that if the business could accomplish everything at the same speed without having to deal with me, they’d pick that option without blinking.

That perspective is actually useful. It contextualizes what we’re all doing in this industry, and it puts a lot of tech debates back in their place. The business doesn’t care whether you use Python or Go. Spending cycles on that rewrite is probably not where the real return is.

What stays consistent across every industry, though, is the fragmentation problem. Regardless of sector, every engineering org has data scattered across a dozen tools with limited connective tissue between them. The specifics vary: regulated industries have longer planning cycles and lower tolerance for ambiguity in requirements because the cost of building the wrong thing is higher. High-velocity tech shops accumulate hidden debt faster. But the core failure mode is the same. Teams can tell you what shipped. They can’t trace why something slipped, what it cost, or where the risk was visible before it became a problem. That’s what shaped how we built the platform.

There’s a growing narrative that AI is accelerating coding itself while exposing weaknesses elsewhere. Why are requirements, planning, and spec readiness becoming the real bottlenecks?

We’re seeing this daily. With a good agent and a solid harness around it, you can move from idea, sometimes directly from a customer’s mouth, to production in literal hours.

Part of what makes that shift so significant is the change in the feedback loop. With copilot-style tools, the human is in the loop on every suggestion. The AI offers a completion; you accept or reject it immediately. When it’s wrong, you catch it fast. The blast radius of a bad suggestion is one line of code. Agentic coding works differently: you give the agent a goal, it decomposes the work, executes a multi-step plan, and delivers a working module. The human reviews the output, not each step. When the spec is wrong, the agent builds the entire implementation to that wrong spec and you find out at review.

That sounds like pure upside until you recognize what the previous lag time was actually doing. The lag served a real purpose. Multiple rounds of smart people reviewing, planning, testing, and working through ideas to produce a better system.

The temptation now is to vibe something out and bypass all of that. But agents and harnesses aren’t ready for the full SDLC yet. The speed is real. The quality gatekeeping that used to happen across all those slower steps hasn’t been replaced. That’s the gap.

Many organizations still measure productivity using outdated metrics. What are leaders getting fundamentally wrong about productivity in an AI-driven development environment?

People have matured on this topic considerably since we started Allstacks. Measurement has moved toward things that actually matter, and frameworks have gotten more sophisticated. AI upends all of it.

Traditional software development was fundamentally limited by how fast a developer could write code that met the requirements of the business and the underlying technology. That cost is approaching zero. What we’re moving toward is something closer to an individual developer as a manager of agents. That model requires a completely different approach to measuring productivity, one that’s grounded in something other than tokens generated or developer-hours spent.

Part of the danger with the current metrics is that they hide what’s actually happening at the team level. Senior engineers with AI tools are compounding their advantage: they have the codebase context and the judgment to steer agent output and catch its failures. Earlier-career engineers often generate the same code volume but spend more time auditing output they can’t fully evaluate. Aggregate velocity looks fine, maybe even improved. The gap between those two groups doesn’t show up anywhere in a standard dashboard. The right question to start asking is not “how much faster are we going” but “how much of what we shipped was right the first time.”

We don’t have industry consensus on the right measurement model yet, but teams that start tracking output quality and rework rate, not just throughput and adoption, will be better positioned than teams that wait for someone else to figure it out.

Your platform connects data from tools like project management systems and code repositories. How important is it to unify these fragmented data sources, and what happens when organizations fail to do so?

Allstacks has been successful in this space because we’ve been building context graphs since before that was a term. We recognized early that connecting all the data together was necessary to answer the questions customers were actually asking.

When that connection doesn’t exist, AI operating on your engineering data can only see part of the picture. It can analyze what’s in your project management system. It can analyze what’s in your code repository. What it can’t do is trace a delivery delay back to a blocked dependency across three tools, because the relationship between those signals doesn’t exist in the data layer. You get shallow analysis at best, and confident, wrong recommendations at worst. Model quality doesn’t solve this. You can put the most capable model available on top of raw API integrations and still miss the actual cause of a problem because the data doesn’t encode the relationship between the signals. Garbage in, garbage out, regardless of how smart the model is.

That connection is the foundation. It’s what enabled us to be first to market with capabilities that still haven’t been replicated.

As AI agents become more embedded in development workflows, what does a well-prepared engineering organization look like compared to one that is not ready?

Ironically, it’s not that different from being prepared to bring in a class of summer interns. You need strong automated test suites, solid documentation, a mature CI/CD pipeline, and the guardrails you’d put in place when you’re adding a trusted but untrained developer to the team.

What’s also important, and people tend to underestimate this, is coming back regularly to review the basics: your agent rules, your AGENTS.MD files. You can do a solid first pass, but it’s easy to get into a rhythm of shipping in the new way and forget that you can actually train away a lot of bad defaults. Things like teaching the agent to run tests before every commit shouldn’t require a human reminder every time.

One diagnostic question I’d put to any engineering leader: can you tell me what your agents produced last sprint, which of that output was accepted as-is versus revised, and where the revision effort was concentrated? If you can answer that, you have the instrumentation to improve. If you can’t, you’re flying by feel.

You’ve emphasized the importance of aligning engineering work with business outcomes. How can organizations bridge that gap in a practical and measurable way?

I’ve seen two main failure modes. The first is companies that don’t pair engineering teams with products. Many team structures are legacy and have been in place for a long time. One team might own a piece of three different products while another owns four entirely. Engineering investment largely comes down to headcount, and when teams aren’t aligned to products, it becomes very hard to see where business expectations diverge from reality.

The second failure mode is not accounting for all the work that goes into building and maintaining software. There’s a huge category of business-invisible engineering work. My favorite example is keeping packages updated. Non-technical business leaders often struggle to understand the value or why it’s ongoing and unpredictable. But they can understand investment categories. If you frame it as “critical security upgrades” and show on average how much capacity it consumes, you’re speaking a language they can work with.

If you ask a sales leader to choose between some npm package updates and the feature they need to close a deal, the feature wins every time. But if you frame it as “we fall out of SOC compliance or we ship this feature,” now you’re showing them two tradeoffs they can actually evaluate. That reframing is the whole game. We’ve seen customers cut their R&D capitalization reporting time by more than two-thirds just by making that work classification automatic rather than manual. The mechanism is the same whether the goal is capitalization reporting, headcount justification, or proving AI ROI: connected data replaces correlated spreadsheets.

Given your background in both hands-on engineering and teaching web development, how do you see the role of developers evolving as AI takes on more of the coding workload?

Frankly, I’m a little worried, though I trust that smart people will figure it out.

My concerns are real. Fresh graduates will soon be entering the workforce having never coded in a world without coding agents. Has education caught up to that? The tools move quickly; higher ed doesn’t always move alongside them. The other shift I’m watching is the blurring of senior engineers and senior product people. The most successful practitioners in the new model are engineers who are deeply invested in product thinking.

What becomes more valuable is judgment: the ability to define a problem precisely enough for an agent to solve it, evaluate whether the solution is correct, and catch the subtle failures that pass CI but create architectural problems later. Senior engineers compound their advantage because they can steer agent output and know which outputs to trust. The concern is for the earlier career path. The traditional way of building that judgment was to write a lot of code and learn from the mistakes. That feedback loop is changing in ways the industry hasn’t fully worked through yet.

That said, history offers some reassurance. There was a significant contingent of people who believed compilers would put assembly developers out of work. The technology shift happened as they predicted. What happened to the developers who didn’t follow the same script? Over the following decade, the total number of developers grew. Many of those assembly programmers learned a new language and excelled because of their foundational knowledge. I think a version of that pattern plays out again.

Looking ahead, how do you see AI reshaping the software development lifecycle over the next three to five years, and where will companies gain the biggest competitive advantage?

We’re going to see a feature arms race unlike anything we’ve seen before. As the cost to build approaches zero, companies, even large ones, face a new constraint: collecting and validating enough customer feedback to keep building quality things at scale.

The shift that has to happen is that the bar for what gets built needs to go up. The current constraint in most engineering organizations is simple: five top priorities, maybe two delivered. With agents, the ratio flips. You might have five top, ten next, and twenty maybes on the list, and ship a hundred. The question nobody has fully answered yet is how you keep those last sixty-five from being poorly conceived and badly executed.

Two things I’m fairly confident about for the three-to-five year window. First, competitive advantage in engineering AI will come from context depth and breadth, not model quality. The models are becoming table stakes; every tool will have capable ones. What will differentiate the leading platforms is how deeply they understand your specific organization: your repos, your team structure, your delivery history, your deployment patterns. The tools that know your system will produce fundamentally different answers than the ones that don’t. Second, the shift from reactive to proactive. Today’s tools answer questions when asked. In a few years, the leading tools will observe continuously and surface risk before you ask. Organizations that build that context layer now are compounding an advantage. The next generation of tooling has to solve the quality-at-scale problem, and the organizations that figure it out first will have a real edge.

Thank you for the great interview, readers who wish to learn more should visit Allstacks.