Low Code Doesn’t Mean Low Engineering

When I first heard the term low code, I’ll admit I was skeptical.
My initial doubts were about how much flexibility engineering teams could really have in such environments.
As someone coming from a data background, I associated engineering with writing code line by line, designing systems from scratch, tuning SQL queries, thinking about pipelines and infrastructure. “Low code” sounded like something simpler. Lighter. Maybe even limiting. Then I stepped into the world of enterprise banking software and into the ecosystem around the Pega Platform as an Engineering Manager. And I realized very quickly that low code doesn’t mean low engineering. In many ways, it simply shifts where engineering happens.

Why Low Code Fits Banking So Well

Banking is full of processes. There are approvals, compliance checks, risk assessments. Customer journeys that must be documented, traceable and auditable. Many of these processes used to be manual, fragmented, or dependent on legacy systems that evolved over decades. This is exactly where low-code platforms shine. They provide structured environments, architectural guardrails, reusable components and clear workflow modeling capabilities. In industries where processes are complex but well-defined, that structure is powerful for developing software. Instead of reinventing the wheel every time, teams work within a framework that already understands cases, stages, decisions, and integrations. But that structure doesn’t eliminate engineering responsibility. Guardrails integrated in the platform don’t automatically create good systems but engineers do!

The Myth of Simplicity

One of the biggest misconceptions about low code is that it removes complexity. It doesn’t. It removes some technical friction and it accelerates delivery. But complexity still exist just in different forms. There are always multiple ways to build a solution. Quick fixes can become long-term architecture. For example, someone can choose to use temporary values instead of properties and it can make things very complex when the application gets bigger and prevents you to make changes easily. Naming conventions matter. Data models matter. Integration patterns matter. In low code, you don’t deal with syntax errors all day. You rather focus on design decisions. And that’s where engineering and therefore fun truly begins.

Engineering Happens in Conversations

One of the things that surprised me most when I joined was how much engineering happens outside the platform itself. In refinement meetings, everyone joins: developers, business analysts, quality engineers, product owners. We don’t just estimate effort. We discuss confidence. We challenge assumptions. We explore edge cases. Pega Senior and Lead System Architects are not expected to simply implement requirements. They are expected to challenge them based on technical knowledge and domain understanding. They ask questions such as “Does this scale?”, “Is this aligned with our architecture?”, “Is there a simpler way?”. These discussions are sometimes intense, often detailed, and always collaborative.
Low code does not eliminate engineering depth. It shifts the focus toward architecture, design quality, and collaboration.

More Than “Just” Pega Developers

Another misconception is that working with a platform like the Pega limits your technical growth. In reality I see the opposite. Some engineers in our teams dive deeper into frontend topics, refining user experiences and improving accessibility. Others sharpen their SQL skills to ensure performance and clean data structures. Knowledge of Java becomes valuable when building custom components or understanding what happens under the hood. On the data side, Python is becoming more relevant. For example when working with orchestration tools like Apache Airflow to manage database connections and pipelines. And of course, cloud knowledge matters when operating in environments powered by Amazon Web Services. Low code is not a technical cage. It’s a center of gravity. Around it, there’s so much space to explore if you want to grow further.

From Skepticism to Curiosity

Today, when I sit in discussions about platform upgrades, refactoring initiatives, or strategies to improve automated testing, I don’t hear ‘low code’. I hear engineers debating trade-offs. I see people who care deeply about quality and maintainability. And I see cross-functional teams taking ownership of the systems they build. My journey started with some skepticism, moved through mild annoyance at unfamiliar terminology, and evolved into genuine curiosity and motivation. Now, I’m not just observing from the outside. I’m excited to be part of the conversation and to help create an environment where engineers can grow, challenge, and shape systems that truly matter. Because in the end, engineering isn’t defined by how much code you type. It’s defined by the responsibility you take for what you build.

A special thank you to my fellow Engineering Managers (Hannah, Holli and Marga) and our Pega Chapter Lead (Raphaela) for their thoughtful feedback on this article. The journey that started with few misconceptions has turned into genuine curiosity and excitement. I’m very glad to be part of the team :)

Written by Elif Schaefer, Engineering Manager (Pega)