DEV Community

Cover image for Cloudy With a Chance of Context: Navigating Change with Context Engineering
Anthony Barbieri
Anthony Barbieri

Posted on

Cloudy With a Chance of Context: Navigating Change with Context Engineering

Simply writing code was never the bottleneck for software engineering. Software engineering is much broader than programming and involves the end-to-end delivery of value. While shifts like the DevOps movement have pushed teams toward greater ownership, there is still an ever-increasing number of responsibilities overwhelming development teams. Something had to give.

To understand the scale of the change we are now facing, we must look back at the radical shift that occurred in infrastructure engineering with the adoption of the public cloud. The historical bottlenecks of physical specification sheets and manual capacity planning were causing unacceptable delivery delays. Cloud computing fundamentally raised the abstraction line, moving an engineer's focus away from physical assets like servers and toward logical, API-driven services. Concepts like Infrastructure-as-Code (IaC) became the norm, transforming the role from hardware maintenance to architectural optimization and ultimately driving a focus on higher value activities.

The public cloud did not come without its own risks. While it allowed teams to move with incredible speed, it tested the ability for safety guardrails to keep pace. Early on, you couldn't go long without seeing a breaking news headline about another public S3 bucket that had exposed sensitive data. This highlighted the need to clearly understand the implications of the various knobs and switches these cloud services made available.

Platform engineering teams entered the scene to help development teams navigate the complexities of the cloud while allowing them to focus on their functional requirements. However, development teams always outnumber platform teams, and enablement teams can only scale so far. This leaves a gap of teams that may be pioneering on their own and cannot easily get the answers they need to follow best practices.

Having worked in the security and platform engineering spaces, I am genuinely excited with some of the potential from generative AI, specifically agentic coding agents. Rather than catching something in a CI/CD pipeline or after having already been deployed, a well-configured agent can inject guidance and corrections during code generation. This helps address some of the scaling issues plaguing platform teams and other teams with governance responsibilities.

If you ask five different developers to build something with a one sentence description, you'll almost certainly get five different answers. Coding agents are no different. Without the necessary context they may completely miss the target outcome or fail to follow internal best practices.

Security policies, style guides, and internal opinions all become critical context to provide the agent. The challenge becomes finding the right mix of these sources at the right time. The industry is currently calling this "context engineering" as of late 2025. Owners of these sources need to meet developers where they are by making them available for agents to consume. Once that context is available, a coding agent may be guided to ensure an API call is made securely over HTTPS, discouraging a developer from using verify=false to skip certificate validation. Or it might auto-apply parameters to a database configuration to ensure it is encrypted at rest.

Beyond improving overall code quality, there is also the potential for developers to be more informed on the why behind certain configurations or approaches. When working in larger companies, it can be hard to understand the history or wider architecture that might drive a certain approach. With GenAI, a developer can interrogate and re-frame concepts to ensure they get the necessary learning at the right time.

Between the improved adherence to best practices and ability to quickly ramp up on a topic, developers can be more focused on delivering value for their business domain. They can finally experience a similar shift to what infrastructure engineers went through during the cloud transition.

Most definitions of software engineering highlight that the ultimate outcome is to build solutions that meet user needs. The means of achieving that value, however, is undergoing a fundamental shift. Skill sets must change to match the moment, moving more of our focus from coding to clear specification and context engineering. This will help ensure we don't repeat the security and consistency mistakes we made during the early cloud transition. Governance and platform teams can lead this change by making machine-readable guidance available to agents. I encourage everyone to embrace this change with curiosity and see what's possible!

Top comments (0)