For seven years, one of our colleagues has worked across software development and leadership roles, moving through enough products, architectures and project decisions to say, with some understatement, that he has “seen stuff.” His route into engineering started much earlier, with HTML and CSS experiments as a teenager, but first took him through a degree in psychology and the prospect of an academic career.
Today, he works at the intersection of site reliability, systems design and AI-native development. What interests him most is the difficult work that comes before implementation: understanding what the business and the customer need, then translating that into systems that can remain reliable as the product changes.
He asked to remain anonymous, but his perspective belongs in The Art of Solving. We spoke about moving from psychology into technology, what leadership teaches an engineer about product success, why systems become difficult to change, and what engineers still need to understand when AI can produce code faster than they can inspect it.
What first made you want to become an engineer?
I started experimenting with programming when I was around 12. I had created a themed group on a social platform and began customizing it with HTML and CSS. I liked that I could put something into the world that was more than text; it could be visual and interactive.
That made me curious enough to ask my parents to enroll me in programming courses. The local lab was already using fairly outdated technology, even for 2008 or 2010, and I did not enjoy it immediately. Once I understood how things worked, however, I became much more interested. I built a few test websites and even took on some very small freelance projects. Realizing that I could earn money from something I enjoyed was a surprise.
At that point, I still thought of development as a hobby. I wanted to study psychology and imagined that I might pursue an academic career, so I completed my degree in that field. Becoming a software engineer was an unexpected turn.
What changed your mind about pursuing psychology academically?
The career prospects were limited, particularly where I lived. Meaningful research requires access to large, varied cohorts and considerable resources. Without that scale, it is difficult to produce results strong enough to support or challenge a hypothesis.
My bachelor’s research examined how social media affects communication. I could survey around 400 or 500 people, but I felt that repeating the same study with a different group could produce very different results and take the research in another direction. To do the work properly, I would have needed far more resources or the opportunity to move somewhere with better access to funding.
Psychology does not attract abundant funding, so you often need an established reputation before you can secure meaningful grants. I was not prepared to build my life around such an uncertain path, particularly when I also had a family to support.
How did you find your way back to software development?
Around 2014, software engineering was expanding quickly and many people were entering the industry from unrelated backgrounds. I had already used programming for statistics during my psychology degree, and I remembered enjoying web development, so I decided to try it seriously.
Through a friend, I met an experienced developer who became my mentor. He gave me direction and helped me structure what I needed to learn. I discovered that the work suited the way I think and that I learned it quickly. I completed what was meant to be an eight-month course in roughly two months, then continued beyond the original material.
I started applying for jobs with no professional experience. The first few interviews went badly, but they taught me how technical interviews worked. I received my first offer after five or six attempts.
What has kept you interested in engineering since then?
There has always been room to grow. New tools and approaches appear faster than anyone can fully absorb them, which can be demanding, but it is also evidence that the field is still moving. I remain confident that there will be new problems to solve and new ways for me to develop.
I joined Bytex about three years ago and was surprised when my first interview was directly with Apple. I had assumed the project would involve a third party working somewhere around Apple, so receiving the invitation from Apple itself was a big moment. I have now been working with CodeRabbit for about a year, which has given me another opportunity to work with a significant technology company.
Tell me about your current role. What occupies most of your attention?
The industry has changed significantly over the past six months. Many companies are still working in familiar ways, while CodeRabbit has embraced AI-native development and is operating at the front of that shift.
Instead of engineering only the product or the code, we are increasingly engineering the workflows through which AI agents produce code. That means connecting the technical components, controlling cost, building agents for specific tasks and designing a process that produces reliable results. With the right setup, the same engineer can accomplish far more.
My role is focused on site reliability. When something happens, I investigate the cause, resolve what I can and escalate the issue to customer support or the engineering team when necessary. Increasingly, I look for patterns before customers report them. I may identify a problem affecting one customer, investigate further and discover that 50 more are affected. By the time someone contacts us, the problem may already have been fixed.
You have worked in both engineering and leadership positions. How has that changed your understanding of what makes a project successful?
Leadership taught me that success is not determined by the volume of work completed or by the technical achievement alone. What matters is whether the product addresses the client’s needs, how customers respond to it and whether it succeeds as a business.
Earlier in my career, I focused heavily on the technical side and could lose sight of what existed beyond it. Moving into leadership helped me understand that the technical solution is only valuable in relation to the problem the customer is trying to solve.
You described your seven years in technology by saying that you have “seen stuff.” What did you mean?
Working across outsourcing and outstaffing projects exposed me to many different products, technology combinations and ways of working. I have seen approaches that created serious problems later, as well as the historical decisions behind them.
Sometimes a strange technical choice makes more sense once you understand the circumstances in which it was made. That experience helps me recognize where problems come from and what they may turn into.
Looking across the projects you have worked on, which problems tend to repeat themselves?
Software projects don’t usually develop exactly as expected because business owners cannot know what will matter tomorrow. A feature that begins as a minor addition may eventually become the product’s central source of value. The engineers who built it may not have known that it would become so important, so they may not have designed it for reliability, scale or easy modification.
Once the business depends on that feature, changing the original solution becomes risky. New work is added on top of it, the design becomes legacy architecture and maintenance costs continue to rise.
AI is beginning to reduce some of that burden because it makes rewriting legacy systems considerably easier. In the past, one of my strengths was being able to understand what was happening inside a complicated system. That skill is still useful, but the way it is applied is changing as AI takes over more of the mechanical work.
What should engineers ask before they begin designing a system?
The most important questions are often business questions: What value will this feature create for the customer? Why has it been requested? How will it be used?
An engineer should not simply receive a ticket and implement it. Understanding the reason behind the request often reveals a better solution. You may be able to suggest an approach that is easier to maintain, provides a better user experience or solves the customer’s underlying problem more directly. Technical knowledge becomes much more valuable when it is applied to the business problem rather than only to the task description.
Business stakeholders and engineers often describe the same problem differently. How do you establish a shared understanding?
You need visibility into the full path of a request: where it originated, what the customer reported, how support interpreted it and how the business team translated it into development work. Whenever possible, I ask to see the original support ticket, customer request or relevant usage data.
Without that trail, an engineer receives only someone else’s interpretation of the problem. Business stakeholders will not always provide every piece of context automatically, so engineers need to gather that information themselves.
Systems design involves constant trade-offs between speed, cost, reliability and usability. How should engineers make those decisions?
The difficult part is often explaining the available options to the business before committing to one. A technical compromise may be perfectly acceptable if stakeholders understand its consequences.
For example, analytics may update every five minutes rather than in real time. If that delay is acceptable, the business can communicate the behavior clearly and position it appropriately for customers. A trade-off becomes manageable when it is understood, deliberate and reflected in the product promise.
Most systems designs do not require inventing something new. In the vast majority of cases, established patterns already exist. The engineer’s responsibility is to understand those patterns well enough to choose the one that fits the business requirements and explain the implications to people without a technical background.
As AI makes code easier to generate, will engineering become a more strategic discipline focused on designing coherent systems? Or will people eventually stop needing to understand the systems behind their products?
We are already moving toward a world in which some people ship code they do not fully understand. I am uncomfortable with that approach. Engineers should understand what they release and remain accountable for its consequences.
The reality, however, is that teams are under pressure to ship quickly, particularly when competitors are using the same tools. There is often little time to inspect every detail produced by an agent.
As agents become more capable, this may become less of a problem, but engineers still need to design the overall structure in which those agents operate. Giving an agent an unrestricted task and accepting whatever it produces can lead to a bad outcome. A stronger approach is to engineer the workflow: define the steps, provide the relevant context and require the agent to explain its decisions. The agent should work in a way that remains legible to the engineer supervising it.
How can an engineer make an agent work in a way that reflects their own judgment and preferences?
One simple approach is to ask the agent to analyze your previous work. It can review several months of history, identify recurring patterns and describe how you tend to solve problems. From that, it can infer aspects of your working style and apply them to future tasks.
Pattern recognition is one of the things these systems do well. When the agent has access to relevant history and preferences, it can often produce work that is close to what I would have done myself. Without that context, it falls back on generic defaults, which may be poorly suited to the system.
Should this working style remain personal, or should companies create a uniform approach for all employee agents?
I do not think companies need to invest heavily in separate documentation simply to teach agents a company-wide style. The codebase already contains many of those patterns. It shows how the company structures its work, which conventions it prefers and how previous decisions were made. In that sense, the code itself is documentation.
The more important investment is in engineers who use AI responsibly: people who understand what the systems are producing and can evaluate the consequences and trade-offs rather than accepting the output automatically.
