Prologue

It’s that day again — the one that shows up every quarter without fail. You glance at your calendar, and there it is: a long, looming meeting titled “Quarterly Priorities Review.”

On one side, the engineering team. On the other, the product team. Both are bracing for what’s about to unfold. Each comes armed with their roadmaps, data, bug reports, and feature requests. One side fights for stability, maintenance, and laying down solid foundations for the future. The other pushes for new features, faster releases, and a relentless drive to conquer the market at breakneck speed.

Here, priorities aren’t just set — they’re won and lost. By the time the meeting ends, both sides leave with a sense of unease. The outcome? Bittersweet. No clear winners emerge from this clash. But if you look closely, there is a victor: technical debt, quietly growing in the background.

This dramatization might seem like an over-exaggeration (and it is), but it also reflects a reality many teams face. After countless user interviews, this pattern emerged repeatedly. It’s hard to see things from the other side when goals seem misaligned, and when those goals aren’t met, it’s easy to point fingers.

From the engineers, I heard comments like:

• “They don’t fully appreciate the importance of technical debt.”

• “Short-term wins often take priority over long-term stability.”

• “Requirements and scopes shift too frequently.”

On the other hand, from product managers, the feedback was:

• “The significance of this feature isn’t fully understood.”

• “We’re not moving quickly enough.”

• “Our customers are pressing us to deliver this as soon as possible.”

One thing both groups seemed to agree on, however, was that a major pain point — especially in larger companies — is that everything becomes a negotiation. Whether it’s deciding what gets prioritized or balancing the needs of the present with the demands of the future, the process often feels less like collaboration and more like a tug-of-war.

In the end, it’s not just about building features or maintaining stability — it’s about navigating the negotiations to find common ground, and that can be exhausting for both sides.

My experience

One of my first roles after graduating was right in the middle of it all — a “Product Engineer.” In this role, I got to see both sides of the coin and started to better understand the perspectives of each team. As product engineers, our job was to develop quick MVPs — temporary solutions to help the operations team while the engineering team worked on more robust, long-term fixes.

My first task seemed simple enough: “Can you create an automation to help the operations team quickly fill a Google Sheet by cross-referencing data from the sheet and our database to automatically fill in the missing information?” As a young, eager, and admittedly naive engineer, I was ready to make an impact and prove my worth.

I developed the solution in just a few days and iterated on it with the operations team until it met their needs. I still remember the joy on their faces when they clicked the button I had built, watching the sheet fill in automatically, saving them countless hours of manual work. I felt incredible — my work was truly making an impact on others’ lives. What an accomplishment, I thought.

Then came the weekly review. I eagerly presented my solution to the team, but the engineers didn’t seem nearly as excited as I was. That’s strange, I thought, but I shrugged it off and kept moving forward.

Months passed, and I delivered a second and third MVP. The operations team loved them — my solutions were making their lives easier — but the engineering team still wasn’t thrilled. I started to wonder: Are they jealous that I’m delivering multiple solutions while they’re still working on one? Looking back, I realize how naive and clueless I was.

The first hint of what was really going on came when a bug was reported in my first MVP. I jumped on a call to hear about the issue, thinking, No problem, I can fix this in a couple of hours. But when I opened the project, all I saw was a tangled mess of spaghetti code. My initial reaction was, What was I thinking? I stared at the screen, confused. What is this? Why is there a variable named data and another named data_2? It was chaos. What I thought would take a couple of hours ended up taking a couple of days, but eventually, I fixed it.

The real wake-up call came when a bug surfaced in an MVP built long before I joined the company. The frustration was immense — I had to sift through undocumented code, struggling to even locate where the code lived before I could begin to understand it. The pain and frustration of trying to fix something so unfamiliar made me realize just how crucial long-term stability is. When developing for a company, it’s not just about getting the code to run — it’s about ensuring someone can maintain it down the line.

That’s when I truly saw the difference between college homework and working at a company. In school, the goal was to get the assignment done, hand it in, and forget about it. But in the real world, the code lives on — others have to work with it, maintain it, and build on top of it. It’s no longer just about solving the problem; it’s about creating something sustainable.

If someone reading this has had to endure the pain of maintaining the first MVPs I created, I want to say I’m sorry. You can have a beer on me next time for all the pain I caused!

I can only imagine that problems like this have become even worse since tools like ChatGPT. While it’s now possible to create solutions faster than ever, the downside is that even the developers themselves may struggle to fully understand how those solutions actually work.

The future

Using tools like ChatGPT to code carelessly is likely to become the norm, especially as college graduates learn to rely on these tools to complete their homework. However, the solution may lie in the same place as the problem. We can leverage these tools to help developers gain context on what was built and why it was built that way. That’s a big part of what we’re working on at Blar.

So, how do you solve a problem like this? I don’t want to oversimplify it — truly aligning incentives requires a real cultural shift from both sides. And even that might not be enough in a world that’s constantly accelerating, where priorities change quickly and often.

That said, we believe we can at least help by centralizing data and developing an AI that understands both the code and the product requirements. Why is this important? Because developers rarely write code for its own sake; they build it to serve a purpose. To truly understand the code, you need to understand why it exists in the first place.

Imagine an AI that not only understands legacy code but also comprehends the product requirements from which this code originated. Not only could engineers use it to make sense of legacy code and understand what’s going on with that MVP that’s critical for operations, but product teams could also use it to verify that their requirements are being fully met and considered.

We believe in creating an AI that acts like a veteran engineer who’s been with your team since day one, fully understanding the codebases and their evolution over time. Nowadays, no single engineer can keep track of every change made to the code or grasp every last detail. But with an LLM that has access to the right data, we could bridge that gap and provide this level of deep insight.

But let’s not get ahead of ourselves. We’re starting by addressing the problem from the engineering perspective, helping developers gain deeper insights into the code. Our agent traverses the codebase, assisting engineers in tackling technical debt, finding bugs, and making the code more efficient. This is a reactive solution, addressing what already exists. But we also offer a proactive approach by catching potential errors during the Pull Request process, making the code more robust and the review process less painful and tedious for developers.

Our aim is to help developers move quickly without the constant fear of accumulating technical debt. We believe in a future where speed doesn’t come at the cost of stability — where we can build a long-term memory of the code and its changes. Our vision is to align product and engineering goals more effectively. While differences will always exist, our goal is to find a middle ground where both sides can collaborate and focus on what truly matters: delivering value and creating a great experience for both customers and developers.

“The ultimate purpose of software is to serve users. But first, that same software has to serve developers. This is especially true in a process that emphasizes refactoring”
Domain-Driven Design: Tackling Complexity in the Heart of Software” by Evans Eric, Credits also to Minor Arrieta as he posted it on LinkedIn

Closing Remarks

If these challenges resonate with you, let’s connect! At Blar, we’re on the lookout for 2–3 design partners to collaborate closely with, diving deep into their issues and crafting robust, long-term solutions together.

Let’s transform the way we approach development! Connect with me:

• LinkedIn: Jose Dominguez

• X: @LePeppManu

• Blar: blar.io

Together, we can create something impactful!

Thanks for reading!