The future is now… which is now “then.”
Do you remember where you were on November 30th, 2022. If you were in the US (or perhaps Liberia or parts of Mexico as I have recently come to learn), you may have been sitting around the house eating leftover turkey, or a nice ham sandwich (if you were fortunate to have both available on Thanksgiving).
November 30th, 2022 was the launch date for ChatGPT.
Although it was very rough around the edges and not ready for prime-time, many immediately saw into the future. I cannot say that I did immediately, but I was out there experimenting, watching it “lie” to me. Those “lies” were quickly labeled hallucinations and sounded much cooler. Anyway the race was on apparently. Not that I was fully paying attention at the time.
Like most engineers across infrastructure, hardware, or software, I’ve spent the last four years just trying to keep my head above water. Figuring out what to learn and what to ignore has become almost as exhausting as the actual learning process. On one side, you have the performative hype from influencers desperate to prove how far ahead of the curve they are. On the other, there’s a deafening wall of noise from frontier model providers and newly christened startups, all frantically trying to dump a product before their razor-thin window of entrepreneurship slams shut.
As a traditional infra-engineer, LLMs and agentic coding have been quick to deliver value. I have never identified as a software engineer, but rather a hardware and infra-centric practitioner. I’ve spent my work-life architecting, deploying, and supporting Unix/Linux, virtualization platforms, and enabling hardware functions such as SR-IOV for Telcos across North America.
I’m the guy who knows the difference between raid 0+5 and 5+0.
Suddenly, I am now a technologist who now has the tools to quickly deliver true infrastructure as code without having to become an evangelist for any specific automation platform. Suddenly, its much easier to deploy tools, supporting services, create dashboards, and troubleshoot and resolve system/hardware issues.
Strangely I have always loved creating documentation, and have spent many years being frustrated with the lack of documentation that I have seen from others. To me, a measure of success is the fact that a solution that you built, is still relied upon once you are gone. Without proper documentation, and the ability for your successors to truly understand, operate, and enhance something that you built is dependent on great documentation. If you can not transfer the appropriate level of operational and design knowledge to those who replace you, they will replace your solution as well. With AI, everyone now has the power of documentation. “Review this repo and describe how it works, update the README.md”. It’s truly a wonderful thing.
The Micro-Eras of Agentic Coding
Having done my best to keep up via reading, experimenting, and building, I have learned quite a bit in a very short time. Those who share the same passions and beyond are often learning the same things at the same time. Separately, but also together, as they uniformly change the vernacular of agentic coding. First, we learn how to prompt from the perspective of a persona, defining outcomes. Next, we discover the need for guardrails and frameworks, especially when the word security rears its ugly head.
Nothing below is unique or original, and I am not sure that there is actually a difference between 3 & 4, or possibly the Eras are in the wrong order, but here is my table for trying to keep straight concepts and terminologies that describe those contexts
| Era & Focus | The Primary Problem Solved | The Technical Stumbling Block | The AI Engineer’s Job |
| 1. Prompt Engineering (2022-2023) | Expression: Shaping the tone, persona, and output formatting of the LLM. | Hallucinations: Cannot conjure up data or facts it wasn’t trained on. | Writing clear, contextual instructions and few-shot examples. |
| 2. Context Engineering (2023-2024) | Information: Injecting real-time, proprietary data via RAG and Vector DBs. | Passivity: The model can read your data, but cannot act on it or use tools. | Managing token budgets, chunking data, and optimizing semantic retrieval. |
| 3. Harness Engineering (2024-2025) | Environment: Giving the model tools, secure sandboxes, and safety guardrails. | Rigidity: Linear chains break completely when the model makes a minor mistake. | Building secure execution environments, MCP servers, and input/output parsers. |
| 4. Loop Engineering (2025-2026) | Autonomy: Letting the system evaluate, self-correct, and iterate recursively. | Compute Cost: High token consumption due to repetitive agent cycles. | Designing state machines, testable termination conditions, and exit criteria. |
“It’s all vibecoding, right”
The term “vibe-coding” was officially coined by Andrej Karpathy (former Director of AI at Tesla and co-founder of OpenAI) in a viral post on X (Twitter) on February 8, 2025.
And it’s a term that I despise, despite fully understanding how fitting that term was at the time.
Fast forward 1.5 years, and now “vibe-coding” sounds silly and very passe, as to me it implies sitting down with a chat window and an idea, and nothing more. This is what kids do in the basement to build a fun yet forgettable android game, right?
And this is not where we are today. Today we are knee-deep in learning, and imagining what the next step is in this agentic evolution.
Planning, context, guardrails, loops, governance, frameworks, and harnesses is where we are, at least mainly in theory, and sometimes in practice.
Leave a Reply