A few weeks ago, we organized an internal conversation at WyeWorks around a question that has been quietly surfacing across the software industry over the last year:

What does it actually mean to “know how to program” in the age of AI?

The trigger for the discussion was a tweet from Robert C. Martin, where he reflected on how AI tools had already changed the way he works. He mentioned spending less time thinking about syntax and more time focusing on architecture, dependencies, tests, functions, and higher-level system structure.

Robert C. Martin (@unclebobmartin) on how AI changed the way he works

That idea resonated strongly with many of us because it captures something that already feels visible in day-to-day engineering work. The activity of software development is changing, not in some distant speculative future, but right now, inside real teams, projects, and delivery processes.

More and more, developers are no longer writing every line themselves. Instead, they spend a growing amount of time reviewing, validating, guiding, constraining, and orchestrating systems that are partially implemented by AI assistants. The code increasingly comes from somewhere else, while the human role shifts toward judgment and direction.

Naturally, that creates tension.

Do deep technical fundamentals still matter in this new context? Should developers continue investing time reading technical documentation, learning language internals, and studying software architecture deeply? Or are we entering a world where implementation details gradually become secondary, while higher-level reasoning becomes the primary engineering skill?

To structure the conversation, we proposed two intentionally simplified camps.

Camp A: fundamentals still matter

The first position argues that programming knowledge remains deeply important, even in a world increasingly dominated by AI-assisted development.

Not necessarily because developers will continue manually typing every line of code forever, but because someone still needs to understand what is happening underneath the abstraction layer.

In practice, this is the camp of people who still choose to sit down with a Ruby book, or to read the official React guides end to end, in order to learn a language or framework’s features, even when no concrete task is pushing them to. The motivation is mastery of the tools themselves, not just solving the problem currently in front of them.

To be honest, even within this camp someone in the conversation admitted that the motivation to read about language syntax has dropped drastically, simply because the immediate driver for it is no longer there. When an assistant can produce the syntax on demand, the old incentive to study and memorize it naturally weakens.

Several examples shared during the conversation pointed in this direction. One engineer described a situation where an AI assistant repeatedly failed to solve a complex Terraform issue. The eventual solution only emerged because prior knowledge of the tooling and documentation allowed him to recognize the flaw in the generated approach and reason toward a better alternative.

Another participant mentioned that AI feels dramatically more trustworthy when operating inside technologies he already understands deeply. When working outside that comfort zone, the confidence level changes completely, and the need to validate against official documentation becomes much stronger.

That distinction feels important because AI often amplifies existing expertise far more than it replaces it.

Deep knowledge of a technology also pays off in a less obvious way: it is what lets you define the constraints, conventions, and guardrails that coding agents rely on to stay on track. The better you understand a stack, the more precisely you can shape the environment the agent operates in, which directly improves the quality and reliability of what it generates.

Experienced engineers can usually detect subtle mistakes, conceptual inconsistencies, or dangerous trade-offs hidden inside otherwise convincing generated solutions. Less experienced developers, on the other hand, may struggle to distinguish a persuasive answer from a correct one.

And unlike a compiler, AI systems are fundamentally non-deterministic. Two similar prompts can generate entirely different implementations, with varying levels of quality, maintainability, and correctness. Sometimes the result is excellent. Sometimes it works while introducing long-term problems that are difficult to detect initially.

That means responsibility does not disappear. It simply moves.

Camp B: think at a higher level

The second position argued that software development is clearly moving toward higher levels of abstraction, and that this transition is not only inevitable, but already happening.

From this perspective, syntax matters less than architecture. The implementation itself becomes increasingly delegated, while the developer’s primary value shifts toward defining systems, constraints, workflows, and trade-offs.

In practice, this is the camp of people who invest their learning time and energy in architecture and design patterns rather than in the finer points of any single language. The reading list leans toward system design, distributed systems, and the trade-offs between competing approaches.

As a secondary but growing interest, it is also where developers increasingly want to understand the coding agents themselves. As they rely on these tools more and supervise the line-by-line output less, learning how the agents behave, where they tend to break down, and how to steer them becomes a skill worth studying in its own right.

Several people pointed out that code reviews themselves have already started changing. Teams spend less time debating stylistic or syntactic details, and significantly more time discussing maintainability, boundaries, system design, flows, scalability concerns, and architectural coherence.

The act of manually writing code is becoming a smaller percentage of the job.

This does not necessarily imply that technical knowledge becomes irrelevant. Rather, it suggests that the center of gravity inside software engineering is moving upward, toward abstraction and orchestration.

In practice, many modern AI-assisted workflows already feel less like traditional programming and more like systems engineering. The hard problems increasingly revolve around context management, validation strategies, deterministic feedback loops, evaluation systems, and ways to constrain inherently non-deterministic models into reliable engineering workflows.

Prompting alone is rarely the difficult part. The difficult part is building an environment where AI-generated outputs consistently converge toward production-quality outcomes.

The contextual middle ground

The most interesting aspect of the conversation was probably that very few people fully belonged to either camp.

The answer seemed highly contextual.

If you are building a quick prototype, an MVP, or an internal tool, aggressively leveraging AI generation may be perfectly reasonable. Speed and iteration often matter more than deep implementation intimacy.

But when working on financial systems, healthcare platforms, aviation software, infrastructure tooling, or large-scale distributed systems, deep understanding quickly becomes unavoidable again because the cost of mistakes changes dramatically.

One participant raised a particularly interesting concern around the long-term cognitive effects of relying heavily on AI-assisted development. If developers increasingly outsource implementation thinking to external systems, what happens over time to the mental models traditionally built through repetition, debugging, and manual problem solving?

Another participant mentioned already feeling less familiar with parts of the codebase after relying heavily on AI-generated implementations, though he was actively adapting his habits and development practices to counteract that drift. It still feels like one of the most unresolved questions in the industry right now.

Because while the productivity gains are undeniably real, there is also a possibility that some forms of deep understanding become easier to bypass. Historically, many engineering intuitions were built precisely through the slow process of wrestling with implementation details repeatedly over time.

At the same time, refusing to use these tools no longer feels realistic either. The acceleration is too significant, the tooling improves too quickly, and the leverage becomes increasingly difficult to ignore.

Perhaps the real challenge is not choosing between deep knowledge of specific programming languages and frameworks on one side, and software fundamentals on the other.

Maybe the challenge is learning how to operate responsibly at higher levels of abstraction without losing the understanding required to validate what we are building.

Because even if the abstraction layer changes, the accountability does not.