Understanding Before Implementation: My Philosophy of Engineering in the AI Era
Today, an AI assistant can generate a working API endpoint, write a complex SQL query, or configure a multi-stage CI/CD pipeline in seconds. When code generation is nearly frictionless, it is easy to mistake generating an implementation for understanding a system. AI coding assistants excel at boilerplate, syntax, API orchestration, and fast prototyping. But syntax was never the hardest part of software engineering. The harder part has always been framing the real problem, understanding how components interact, identifying constraints, evaluating trade-offs, and knowing how to verify that a system actually does what it is supposed to do. Now that AI can execute code generation on command, conceptual understanding is not less important—it is the very foundation that allows us to command AI effectively.
The Difference Between Framework Proficiency and System Understanding
When picking up a new technology, there are two distinct ways to approach learning:
Learning to reproduce an implementation: Memorizing specific APIs, following step-by-step tutorials, or asking AI to generate code for a framework without understanding its underlying mechanics.
Learning to build a mental model: Understanding what problem the technology was created to solve, why its abstractions exist, where it fits into a larger architecture, and what trade-offs it introduces.
Frameworks and SDKs teach us how to interact with specific abstractions. Conceptual understanding helps us decide which abstractions we need, whether they are appropriate, and when a different approach is necessary.
This does not mean hands-on experimentation is secondary. Theory without practice can lead to rigid, over-engineered designs that fail in production. Rather, conceptual reasoning and hands-on implementation should reinforce each other in a continuous loop:
+-------------------------------------------------------------+
| |
| 1. Build a Mental Model ---> 2. Define Architecture |
| ^ | |
| | v |
| 4. Refine Architecture <--- 3. Implement & Test |
| (via AI, SDKs, Experiments) |
| |
+-------------------------------------------------------------+
When you understand the underlying mechanics, you learn a framework with clear intent rather than copying code blindly.
From DevOps to Agentic FinOps: A Personal Journey
I experienced the power of this philosophy firsthand when I transitioned into the world of AI agents.
My professional background was firmly rooted in DevOps—managing cloud infrastructure, automated pipelines, and operational reliability. I had minimal formal experience with AI or agentic frameworks when an opportunity arose to design an agentic solution for a complex DevOps problem: cloud financial operations (FinOps).
Faced with an unfamiliar domain, I had two choices:
Approach A: Spend weeks memorizing popular agentic framework APIs, copying example agent scripts, and trying to force-fit my problem into pre-built templates.
Approach B: Step back and build a mental model of agentic systems first. What makes an agentic system different from a script or a deterministic workflow? What components are required—reasoning, memory, tool access, state management? How should data and decisions flow?
I chose Approach B.
Before diving deep into specific agent frameworks or SDKs, I focused on understanding the system boundaries and architectural capabilities required for an Agentic FinOps solution:
What exact operational problem were we solving in cloud cost governance?
Which tasks required autonomous decision-making versus deterministic automation?
How would an agent reason about cloud resource data, evaluate policies, and execute actions?
What state and context would need to persist across executions?
Where were the potential security, cost, and reliability failure modes?
+----------------------------------------------------------------+
| Agentic FinOps Conceptual Model |
+----------------------------------------------------------------+
| |
| [ Data Sources ] [ Reasoning Engine ] [ Action Layer ]|
| - Cloud Metrics ---> - Policy Rules ---> - Remediation |
| - Usage Data - Context/Memory - Alerts |
| |
+----------------------------------------------------------------+
By first mapping out the system's core requirements, I could evaluate frameworks objectively. Instead of letting a framework dictate what my system should look like, I used frameworks and SDKs—along with AI assistants—to implement specific, well-defined components of the architecture I had designed.
I began building and testing core components individually to validate feasibility. Did I have every answer upfront? No. Was every part of the system immediately production-ready? No. The architecture continues to evolve as I learn more. But starting with conceptual clarity allowed me to make meaningful progress in an unfamiliar domain without getting lost in implementation details.
Engineering in the AI Era: Taking the Lead
AI tools have transformed how quickly we can move from an idea to a working prototype. But generated code is not inherently secure, performant, cost-effective, or architecturally sound.
To "take the lead to command AI" does not mean typing every line of code manually. It means taking responsibility for:
Problem Definition: Articulating clear, context-rich goals and constraints.
System Architecture: Deciding how components decouple, communicate, and fail.
Critique and Evaluation: Interrogating AI-generated code for security flaws, edge cases, and hidden performance costs.
Validation: Designing small experiments to verify that a proposed solution works under real conditions.
If you don't understand what you are asking AI to build, you cannot effectively evaluate what it returns.
A Transferable Framework for Learning New Technologies
Whether you are exploring agentic AI, Kubernetes, distributed databases, or service meshes, this iterative approach can guide your learning:
Define the Problem: Understand what pain point the technology addresses before choosing tools.
Build a Mental Model: Map out the core concepts, data flows, and state management mechanisms.
Identify Component Responsibilities: Determine what each part of the system does and why it exists.
Evaluate Trade-offs: Analyze cost, latency, security, and operational complexity across different options.
Accelerate with AI and Frameworks: Use AI tools, documentation, and SDKs to rapidly write and prototype code.
Test Core Assumptions: Run small, targeted experiments to validate critical capabilities.
Inspect and Verify: Audit generated code—do not assume "working code" is correct code.
Refine Iteratively: Adjust your architecture as practical findings reveal gaps in your mental model.
Why I Write Technical Content This Way
This philosophy directly shapes how I write technical articles. My goal is not to publish syntax cheat sheets or step-by-step code tutorials that become outdated with the next SDK release.
Instead, I aim to help readers understand why systems are built the way they are, their underlying components, decision points, and trade-offs. Once you grasp the foundational architecture, applying any specific SDK, API, or AI tool becomes straightforward.
Final Thoughts
The ability to generate code quickly is more accessible than ever. But true engineering value lies in judgment, critical thinking, and system architecture.
Before diving straight into implementation or asking AI to generate a solution, take time to understand the problem, the system, and the trade-offs. Use AI and modern frameworks to build faster, but keep your hands on the architectural wheel.
