The importance of User Experience
User experience (UX) is one of the key factors that impact any software business. It plays a major role in increasing conversion rates and driving revenue. In a 2006 Stanford presentation, Amazon engineer Greg Linden revealed that just 100 milliseconds of latency cost the company 1% of sales. Meanwhile, fintech apps retain only 48% of users annually (Alchemer, 2022 Mobile Customer Engagement Report). System failures don’t just frustrate users—they directly erode your bottom line. If the UX is poor, users will leave the application and never come back.
It turns out that everything I just described depends entirely on system performance—or, more generically, on System Reliability, a core quality attribute every engineer should care about. Unfortunately, this attribute is rarely the focus of engineers; it’s usually left to architects. This is what you, the “Software Engineer (Non-Architect),” need to understand: things aren’t like they used to be. The new star, AI, is changing everything around you.
Architecture Is the Last Line of Trust
Coding skills are becoming less important than before. Vibe coding—code generated by LLM agents—can now perform at the level of a senior engineer, if not better. This shifts the ground for engineers who focus solely on coding best practices. I’m not claiming best practices no longer matter; I’m saying you are no longer the sole source of code generation.
The one space that remains a true source of trust is Architecture. An LLM can do exactly what you tell it to do—it can build a project in a few hours—but experience shows it can’t guarantee a reliable or maintainable system. Deciding that direction is still your job. You can ask AI to handle it for you, but without your supervision, it won’t deliver what users will love. Architecture qualities like scalability, security, portability, evolvability, and the rest of the “ility” family require your guidance. If you rely on AI alone to get these right, the result won’t be what you expect.
The discussion around Quality Attributes requires lots of papers, I’d like to share with you here a quick example for a skills that AI may not be the right source of dealing with it—Taken from our book: The Highway Path to Scalable Systems
Why do we care about failures?
In the beginning, when only a few users use your system, you probably will not face any issue. Failures appear when the system scales up. Typically, companies aim to attract a lot of users to their system, and with such an increase, the load on the system will also increase. Handling system load is crucial to maintain user satisfaction.
In distributed systems, failures are inevitable. Your payment gateway will time out. Your database will slow down during peak hours. A network partition will isolate your services. The question isn’t if failures will happen—it’s when. Engineers must design systems that appear stable to users even when components are failing behind the scenes.
Popping up a server error page to the user is not a good user experience—in fact, today users become more and more sensitive to such issues—and this will impact the conversion rate. Slowness and waiting time are another common issue that users hate. If your system’s web page processes a request for too long (a few seconds), the user may decide to leave your system and never come back.
Failure is not only about showing the problem to the user but also about sharing accurate information with the user. Notifying the user that their request was fulfilled successfully when it was not is a critical issue that today’s users won’t accept. If the system claims to have fulfilled the request successfully, it must be true; otherwise, it is also a failure.
Reasons for system failures vary. They can be due to code bugs, hardware failures, network issues, or external dependencies. They can be due to a developer mistake or due to unrecognized system limitations. In all cases, any event where the software behaves incorrectly in the face of the user is a failure.
Every engineer should design for graceful degradation. When Twitter’s image service fails, users still see tweets just without images loading. The core value remains intact even when components fail.
Do you think about resiliency?
Vibe coding with AI is indeed fast—it’s amazing at writing code quickly. But writing code is just one step in the Software Development Life Cycle (SDLC). The real value only comes when you achieve customer satisfaction: users happy with the time it takes to get a service from your system, not angry because a failure page popped up in their face when your backend hit an issue. Designing for that outcome is exactly what an Architect does. Now, it’s you.
You can use AI however you like, but if you want to deliver production-ready software, you need to be the one driving. Take the time to design the system carefully before you ask anything of AI—that’s how you end up with a future-proof, maintainable system that’s easy to change later. How can you do that if you don’t know software architecture principles and patterns? The second habit worth building is reviewing before delivering: we’re human, and we lose attention on things we didn’t build carefully ourselves. That’s exactly what happens when AI is given full control instead of you.
Conclusion
UX, reliability, and revenue are the same story told three ways—and none of it happens by accident. AI can write code fast, but it can’t decide how a system should degrade, scale, or fail safely when things inevitably break; that judgment call is Architecture, and it’s still yours to make. Two habits keep it that way: design the system carefully before you hand anything to AI, and review carefully before you ship. As coding stops being the differentiator, understanding Quality Attributes—and building resilient, gracefully-degrading systems—becomes the skill that separates engineers who ship demos from engineers who ship systems users can trust.