AI and the Evolving Role of Software Engineers

Many believe AI will significantly diminish the demand for seasoned software engineers, a notion that is incorrect.

AI’s capabilities are impressive in demonstrations, integrating with tools like Figma for design, Jira for task management, source control for history, and CI/CD for deployments. A feature request can trigger code generation and a pull request, making the development process seem highly automated.

While this automation might seem like a logical progression in software development, its real-world application faces considerable limitations.

These impressive demonstrations are based on the premise of flawless inputs: Jira tickets detailing every business rule, acceptance criteria covering all edge cases, a perfectly consistent design system, thoroughly documented dependencies, and absolutely no lingering questions or ambiguities.

Having developed software for enterprise systems for over two decades, I have yet to encounter a task request that meets such high standards.

Actual task descriptions are typically approximations, conveying general intent rather than exhaustive details. They draw upon unrecorded insights from discussions, past choices, chat logs, and undocumented architectural norms. They also embody compromises reached informally and depend on the implicit understanding possessed by veteran engineers.

While automation thrives on clarity, real-world software development is frequently shrouded in uncertainty. This has significant ramifications for development teams, primarily reinforcing the indispensable role of experienced engineers, whose value is now greater than ever.

The Cost of Vagueness

The inherent uncertainty in software development doesn’t negate the potential of AI-driven automation. Instead, it underscores that automation’s success directly correlates with the exactness of problem definition. For AI to independently develop a feature, instructions must be akin to a thorough technical specification, with all edge cases preemptively identified, assumptions explicitly stated, and every query resolved before development commences.

The quality of the AI’s output is always limited by the specificity of its input.

This rule has wide applicability. Yet, with AI, discerning the disparity between insufficient input and assured output becomes challenging, as the results often appear refined and authoritative.

I’ve personally leveraged AI to construct complete features. When a problem is articulated with sufficient clarity, AI produces code that compiles, executes, and frequently addresses a wider array of scenarios than initially anticipated. This process gives a sense of efficiency, modernity, and cost-effectiveness.

Despite this, the generated solution often exhibits greater complexity than what I would have crafted manually.

An unspoken truth among developers, myself included, is a preference for efficiency. I aim to write only the essential code, seeking the most concise and elegant solution. This inclination isn’t about cutting corners; it’s about disciplined design. By dedicating time to structural thought before coding, the resulting implementation shrinks. Well-defined boundaries prevent redundancy, precise modeling eliminates conditional logic, and judicious constraints minimize the need for extra layers.

Effective architectural design inherently leads to less code.

AI, however, employs a different optimization strategy. It prioritizes extensive coverage and resilience, foreseeing variations and implementing abstractions for wide-ranging scenarios. While rarely producing incorrect code, its output often proves more exhaustive than what’s immediately required, incurring an associated cost. 

Should requirements shift, you’ll find yourself altering logic you didn’t intentionally conceive. When a defect emerges, you’ll be troubleshooting control flows you never fully analyzed. If a colleague inquires about the rationale for a particular abstraction, the answer might simply be that it was part of the AI-generated solution, not a conscious architectural choice.

While AI lowers the expense of drafting code, it doesn’t diminish the expense of maintaining it.

Maintenance encompasses comprehension, the capacity to predict how system changes will ripple through, and the assurance that simplifying logic won’t inadvertently cause problems. This deep understanding and certainty are human attributes, not AI’s.

Enhanced Speed Magnifies Architectural Quality – For Better or Worse

With clearly defined system boundaries and a cohesive domain model, AI significantly boosts your operational capacity, enabling faster structural expansion. Conversely, if the architecture lacks precise definition, AI will merely expedite the growth of complexity. The technology doesn’t alter the course; it only increases the speed.

This magnifying effect is particularly evident in larger enterprises, where architecture is less about formal diagrams and more about its extensive, evolving history.

Enterprise systems are seldom built from scratch; they typically mature over many years, incorporating choices made under previous limitations and integrating components that are difficult to overhaul. Their stability often relies on unwritten institutional knowledge: insights into why specific boundaries were established, why certain dependencies were limited, and why past refactoring efforts were unsuccessful.

AI lacks access to this accumulated architectural knowledge unless meticulously codified. Even when such data is available, AI interprets patterns statistically, not contextually. It doesn’t recall the system outage triggered by an overly integrated service, nor the internal discussions that led to the isolation of a pricing engine, nor why a team prioritized simplicity over extensibility for a particular module.

Such crucial historical context resides with seasoned engineers.

This experiential knowledge subtly influences critical choices: whether a new abstraction is truly beneficial, if a particular shortcut is permissible, or if a proposed simplification risks destabilizing another system component. These nuanced considerations, though seldom found in Jira tickets, significantly impact the quality of implementation.

As workflows become increasingly reliant on AI, the importance of architectural memory escalates. Lacking it, teams run the risk of rapidly replicating previous errors. When the speed of implementation outpaces the growth of contextual understanding, system vulnerability increases proportionally.

This transformation also brings about a shift in organizational dynamics. For teams to enable AI to implement features independently, they must significantly enhance their requirement documentation. Task tickets need to evolve into nearly formal specifications, ambiguity must be eliminated sooner, and decisions typically finalized during development must now be clarified before any AI model is prompted.

Ultimately, the responsibility for defining system functionality, establishing boundaries, and ensuring new features align with existing constraints remains. AI doesn’t remove these critical tasks; it merely relocates the points of challenge.

A Renewed Focus on Foundational Engineering Expertise

For a long time, profound technical skill was often showcased through writing intricate code, achieving mastery over framework inner workings, or constructing elaborate reactive systems. These proficiencies are still important, but AI’s ability to aid in all of them means they no longer serve as unique distinguishing factors.

What continues to be rare is sound judgment.

Judgment entails discerning when a solution is disproportionately complex for the problem at hand. It involves accurately modeling a domain before implementing abstractions. It’s the self-control to prioritize simplicity over ingenious complexity, and the understanding that each added layer incurs future maintenance overhead.

Throughout my more than two decades in software engineering, I’ve observed a profound evolution in development tools. We’ve transitioned from manual infrastructure to cloud platforms, from extensive frameworks to declarative ones, and from custom configurations to automated scaffolding. Each technological advancement brought with it the promise of enhanced productivity, a promise it consistently fulfilled.

However, one constant has remained: the essential need for careful consideration of system structure before its inherent weaknesses are amplified by scale.

AI represents yet another powerful leverage point, boosting baseline productivity, easing the path for experimentation, and trivializing scaffolding and boilerplate tasks. Yet, resilient systems are not characterized by their rapid construction but by their deliberate and thoughtful design. Functional software does not automatically equate to long-lasting software.

AI reduces the cost of developing software, but it doesn’t reduce the cost of strategic thought. And critical thinking remains the job aspect that dictates whether a system merely works now or endures into the future.