.png){kind=logo}
While AI accelerates code generation, it shifts a heavy cognitive burden toward code review, verification, and technical control, DORA’s 2025 analysis of AI-assisted software development says. AI can increase software delivery speed, but without rigorous engineering discipline, it creates systemic risk.
To understand how organizations can responsibly navigate this shift, we spoke with Michael Rainesh. From aviation software used in more than 30 countries to large-scale manufacturing systems in North America, Michael has over 17 years of experience in the software development area, including 8 years leading software engineering teams and building complex technology platforms across the United States, Canada, and Israel. Today, as Director of Engineering at Portside, he oversees the development of software that supports more than 1,000 aviation operators worldwide and drives major improvements in software quality, delivery, and operational performance.
We asked Michael to share his insider perspective on managing the delicate balance between AI acceleration and engineering integrity.
Michael, recent research highlights that AI coding tools may shift the engineering workload from writing code to reviewing and verifying it. In your experience, what separates useful AI acceleration from risky velocity?
I think the defining factor is human ownership. AI is exceptionally good at drafting solutions, but it lacks the contextual understanding of a company’s specific business logic and architectural constraints. Risky velocity happens when developers treat AI outputs as finished products rather than first drafts. We integrated Generative AI into code reviews for each pull request to enhance the workflow's intelligence, but we made it clear that the developer, not the AI, owns the final commit. When you establish measurable quality indicators and require engineers to actively verify AI suggestions, you gain speed without sacrificing the integrity of the codebase.
As Director of Engineering at Portside, you streamlined how engineering teams work and make decisions. As a result, software release issues fell by 80%, team productivity increased by 20%, and delivery became 40% faster and more reliable. How can this kind of governance help companies adopt AI without losing technical control?
The key is to separate autonomy from fragmentation. Teams should be able to move fast, but they should not invent their own quality rules, architecture standards, or security expectations from scratch.
AI makes this even more important because it increases the volume of code, decisions, and review work moving through the system. If every team uses AI differently, the organization may gain speed but lose consistency. A federated model helps solve that problem by giving teams freedom inside a shared technical framework.
The Center of Excellence does not need to approve every small decision. Its role is to define common standards, reusable practices, quality gates, and review expectations. Then each team can apply those standards in its own product context. This keeps development fast while making sure AI assisted work remains traceable, testable, and aligned with the company’s engineering principles.
Your work on standardized SDLC workflows and quality-driven engineering practices was a part of the operational transformation. The result was an 80% reduction in production release issues without relying on a dedicated QA team. How can an engineering team build quality directly into the development process?
It requires a fundamental shift in the developer mindset. Early in my career, I started as a Software QA Analyst, developing a deep understanding of software quality. So when another software product team doesn't have a dedicated QA team, the challenge is to get the best quality from the software development process with no issues.
I had to come up with a strategy for the process to reduce mistakes and not impact developers' performance. The solution lies in shifting that QA automation mindset directly into the developer's workflow. Quality cannot be a secondary phase; it must be written into the code. This means rigorous peer reviews, comprehensive automated test coverage created alongside the feature, and strict release discipline.
You also introduced performance delivery metrics and structured review processes across the engineering teams you lead, driving a 20% increase in throughput. Which engineering metrics are actually useful, and which can be misleading?
Metrics should guide conversations, not punish teams. Misleading metrics usually revolve around sheer volume, like lines of code written or the number of commits. AI can inflate those numbers overnight, creating an illusion of productivity. The useful metrics are the ones tied to stability and delivery confidence.
I look at defect trends, deployment frequency, and the reliability of our burn-down rate, which I’ve historically improved through Agile methodologies. An increase in throughput is only valuable if the production release issues remain near zero. If throughput goes up but the rollback rate increases, your metrics are telling you that your review quality is failing.
At Price Industries, a long-established market leader in commercial climate-control systems, you led an AI proof of concept for a discount system that later helped push the company toward a dedicated data team and centralized data warehouse. What did that experience teach you about moving from an AI experiment to a permanent organizational capability?
I learned that an AI model is only as powerful as the data infrastructure supporting it. We got great outcomes pioneering that POC, but we quickly realized that to scale it, the business needed a foundational shift. You cannot sustain AI in a vacuum. Transitioning from an experiment to a capability requires establishing stakeholder trust, securing high-quality, centralized data, and creating continuous feedback loops. The AI itself is just the tip of the spear; the real organizational capability is the centralized data warehouse and the cross-functional teams that maintain the business context feeding that model.
You pioneered an AI approach within the company by promoting research outcomes to key stakeholders, which resulted in the establishment of a dedicated AI department. How does an engineering leader know when an AI initiative is mature enough to become a formal organizational function?
It comes down to measurable usefulness and repeatability. A demo is easy, but a sustainable internal capability solves a recurring, expensive business problem reliably. I always look for efficient and optimized solutions internally as a tech leader. When an AI experiment consistently removes friction or generates clear value (and you have the data infrastructure and leadership buy-in to support it long-term) it is time to formalize it. You know it’s mature when other departments start relying on the AI’s output to make their own critical decisions.
Distributed teams that move incredibly fast run the risk of burning out or working in silos. In your current aviation software role, you have recruited, developed, and managed global engineering talent, ensuring expertise continuity. You also facilitated pairing sessions to strengthen collaboration and accelerate knowledge sharing. How do leaders protect engineering culture amidst this rapid pace?
You protect culture by making mentorship and psychological safety non-negotiable. I am very careful with the workload for my direct reports, always trying to bring a balance between efficient work and a great workplace culture. Fast-moving distributed teams can easily become siloed. By facilitating pairing sessions, we force collaboration. Sometimes, as a leader, I like to talk to people in person to show them my mindset and push them out of their comfort zone to trigger growth. When you build strong onboarding processes and encourage continuous learning, speed becomes a byproduct of team cohesion rather than a source of burnout.
Your engineering guidelines and documentation are followed as legacy standards, and peers frequently seek your technical perspective at the onset of new projects. From your perspective as a "go-to guy," what makes a technical standard durable even after its author steps away?
A standard survives if it solves a real problem simply and clearly. If a guideline is just a formal document disconnected from the daily friction developers face, it will be abandoned. I keep clear documentation for people to get easy access to my methods. Durable standards act as guardrails that make a developer's life easier, not harder. My goal is always to find new ways to make the software better and bring satisfaction to the people using it. When developers see that a standard genuinely prevents late-night production fires and streamlines their workflow, they adopt it as their own culture.
Michael, as AI becomes a normal part of software delivery, what should engineering leaders prioritize in the next 12 to 18 months?
I guess leaders must prioritize the evolution of engineering judgment. My own plans for the future involve continuing to develop the skill. As AI handles more of the syntax and boilerplate, leaders need to train their teams to think like architects. We must prioritize system design, security, edge-case verification, and deep team ownership. The companies that succeed will be the ones that use AI to free up human intellect to solve harder, more complex architectural problems.
