{"slug": "from-prompting-chatgpt-to-orchestrating-ai-agents-two-years-as-an-ordinary", "title": "From Prompting ChatGPT to Orchestrating AI Agents: Two Years as an Ordinary Engineer", "summary": "An ordinary engineer describes a two-year journey from using ChatGPT for simple queries to orchestrating multiple AI agents, connecting company knowledge systems via MCP, running local models in iOS apps, and maintaining a project memory layer. The engineer built several iOS applications using Cursor, which shortened the feedback loop and kept ideas alive long enough to become prototypes. Key lessons include the need for explicit context engineering and recognizing that AI cannot compensate for missing domain knowledge.", "body_md": "Two years ago, my interaction with AI was mostly limited to asking ChatGPT questions and checking its knowledge cutoff.\n\nToday, I use multiple coding agents, connect company knowledge systems through MCP, run local models inside iOS applications, and maintain a project memory layer so different agents can continue each other’s work.\n\nI am not an AI researcher.\n\nI am an ordinary engineer who kept experimenting until AI gradually became part of both my development workflow and my daily life.\n\nThis is not a history of the AI industry. It is a personal engineering retrospective: what changed, what did not, and what I learned while moving from chat-based assistance to agent-driven development.\n\nStage 1: AI Was Impressive, but Unreliable\n\nMy first experience with ChatGPT was similar to that of many people.\n\nThe initial response was amazement.\n\nThe second response was scepticism.\n\nIt did not take long to discover that a language model could present incorrect information with extraordinary confidence. I learned the term “hallucination,” and asking about the model’s knowledge cutoff became part of my normal usage.\n\nI later completed introductory AI courses from Andrew Ng and Microsoft.\n\nI did not understand every technical detail, but those courses gave me enough context to recognise an important limitation:\n\nA model producing a plausible answer is not the same as a system producing a reliable result.\n\nThat distinction became more important as I moved from asking questions to using AI to modify software.\n\nStage 2: Cursor Turned AI Into a Development Partner\n\nFor me, the real shift began with Cursor.\n\nBefore Cursor, AI was primarily a place I went to ask for help.\n\nWith Cursor, AI entered the development environment itself.\n\nOne Christmas, I spent three days almost entirely at home, building with Cursor. At the end of those three days, I had created my first iOS application.\n\nThen I built another one.\n\nAnd another.\n\nCursor made the feedback loop unusually short:\n\nThis was my introduction to what later became widely described as Vibe Coding.\n\nThe most important change was not that the model wrote code faster than I did.\n\nIt was that ideas remained alive long enough to become prototypes.\n\nBefore AI-assisted development, a small idea often died during setup, documentation searches, dependency configuration, or framework research.\n\nWith AI, the cost of reaching the first working version dropped dramatically.\n\nRules Were an Early Form of Context Engineering\n\nThe early experience was also frustrating.\n\nThe agent forgot previous decisions.\n\nIt changed files outside the intended scope.\n\nIt solved local problems by creating architectural ones.\n\nIt occasionally behaved as if it had never seen the project before.\n\nThe community’s response was to rediscover software engineering discipline.\n\nWe began writing project rules:\n\nAt the time, this was often described as prompt engineering.\n\nLooking back, it was an early form of context engineering.\n\nWe were not merely trying to write better sentences. We were trying to create a stable operating environment for a probabilistic system.\n\nLimited context made this harder. Long conversations regularly lost important information, and opening a new chat was part of the workflow.\n\nI even required the agent to refer to itself using a fixed name in every response. It was an imperfect but useful signal that the original instructions were still present.\n\nThe implementation details have changed, but the underlying problem remains:\n\nAn agent cannot reliably continue work unless the important context is explicit, accessible, and structured.\n\nAI Exposed My Missing Domain Knowledge\n\nWhile building my first applications, I noticed that my interfaces were consistently unattractive.\n\nInitially, I treated this as a model limitation.\n\nLater, I realised that the missing component was my own domain knowledge.\n\nAI could generate SwiftUI code, but it could not give me design judgement that I did not possess.\n\nIt could implement a button, but I still needed to understand:\n\nAI reduced implementation friction, but it did not remove the need for expertise.\n\nIn some ways, it made missing expertise more visible.\n\nWhen implementation is slow, it is easy to blame the tools.\n\nWhen implementation becomes fast, weak product decisions, unclear requirements, and poor design judgement become much harder to hide.\n\nStage 3: Moving Beyond the Chat Interface\n\nAs models and tools multiplied, I started using APIs and local inference rather than relying entirely on hosted chat products.\n\nI bought a reasonably powerful computer and began downloading models from Hugging Face.\n\nOne model that surprised me was Kokoro TTS. Its relatively small footprint showed me how much useful capability could exist outside the largest hosted models.\n\nI later integrated text-to-speech into an iOS application using the Sherpa ecosystem.\n\nThis introduced a new category of engineering problems.\n\nRunning a model in a desktop experiment is very different from shipping it inside a mobile application.\n\nSuddenly, I had to care about:\n\nThis experience reinforced another lesson:\n\nA model demo is not a product.\n\nThe engineering work begins when the model has to operate inside real constraints.\n\nStage 4: Spec-Driven and Agent-Driven Development\n\nAfter spending a long time in free-form Vibe Coding loops, Kiro’s Spec mode stood out to me.\n\nIt approached AI development through explicit requirements, design, tasks, and implementation steps.\n\nThis felt important because code generation was no longer the main bottleneck.\n\nThe real challenges had become:\n\nSpec-driven development felt less magical than free-form prompting, but it felt more transferable to professional engineering.\n\nThe same transition occurred with project instruction files, skills, goal modes, and agent loops.\n\nThe industry moved from:\n\n“Generate this function.”\n\ntoward:\n\n“Understand this repository, follow these constraints, complete this goal, test the result, and report what changed.”\n\nThat is a fundamentally different type of interaction.\n\nMCP Connected AI to Existing Systems\n\nThe Model Context Protocol generated plenty of debate when it appeared.\n\nSome considered it a major architectural shift. Others saw it as an additional abstraction that might eventually be replaced.\n\nIn my own work, MCP became useful for a practical reason:\n\nIt offered a relatively lightweight way to connect agents to existing tools and data.\n\nI built an MCP integration for my company’s knowledge platform.\n\nThe organisation already had nearly ten years of accumulated knowledge. The problem was not the absence of information. The problem was making that information available within an agent workflow.\n\nOnce the knowledge platform was connected, the agent could retrieve information in the context of an actual task.\n\nThis represented a major change in how I thought about AI.\n\nTwo years earlier, I had asked a chatbot when its training knowledge ended.\n\nNow I was designing a system that gave an agent access to the organisation’s current knowledge.\n\nThe focus had shifted from model intelligence to system design.\n\nCoding Is Easier, but Engineering Is Not\n\nModern coding agents can produce remarkable amounts of working code.\n\nIt is increasingly possible to define a goal, give an agent access to a repository, and let it iterate through implementation and testing.\n\nThat can make programming appear almost trivial.\n\nMy experience has been more complicated.\n\nThe amount of manual typing has decreased.\n\nThe need for engineering judgement has not.\n\nThe work has moved toward:\n\nA successful build is not necessarily a correct product.\n\nA passing test suite is not proof that the requirement was understood.\n\nGenerated code still becomes code that someone must own.\n\nAI has made implementation faster, but faster implementation increases the importance of deciding what should be implemented.\n\nMulti-Agent Development Created a Memory Problem\n\nI now regularly use more than one agent on a project.\n\nClaude may begin a task. Kiro or Codex may continue it. Another tool may take over when the first one reaches a limit or struggles with a particular type of work.\n\nThis sounds like parallel engineering, but the handoff is often the weakest point.\n\nThe next agent needs to know:\n\nWithout that information, every handoff becomes a partial restart.\n\nTo solve this problem for my own workflow, I built QiJu, written 起居 in Chinese.\n\nQiJu records project changes and provides a reusable memory layer for subsequent agent sessions.\n\nWithout it, I spend significant time reconstructing context.\n\nWith it, agent handoffs become closer to continuing a shared workflow rather than starting another isolated chat.\n\nI no longer think of multi-agent development as “using several AI tools.”\n\nThe engineering challenge is creating continuity between them.\n\nThe Most Important Change: Ideas Survive Longer\n\nA few days ago, I spent around thirty minutes building a floating stopwatch for macOS.\n\nIt was a small tool I had wanted for a long time.\n\nThe result was not technically significant, but the process represented something larger.\n\nPreviously, that idea would probably have remained on a list.\n\nBuilding it would have required enough setup and research that the expected benefit did not justify the activation cost.\n\nWith AI assistance, the distance between the idea and a usable first version was short enough that the idea survived.\n\nThat is probably the biggest personal impact AI has had on me.\n\nIt has not made every idea valuable.\n\nIt has made experimentation cheap enough that more ideas get the opportunity to prove whether they are valuable.\n\nAI Expanded My Capabilities and Narrowed My Attention\n\nThere has also been a personal cost.\n\nBecause AI and software occupied so much of my attention, I realised that I was entering an information bubble.\n\nMy daily reading became dominated by models, agents, context windows, IDEs, MCP servers, and product announcements.\n\nTo counter that, I began using AI to generate a daily story about something outside my normal interests.\n\nHistory, art, society, individuals, and unfamiliar parts of the world became part of a collection I call “Stories Outside the Bubble.”\n\nThe irony is obvious.\n\nAI expanded what I could build while narrowing what I noticed.\n\nThen I used AI to widen my attention again.\n\nWhat I Believe After Two Years\n\nOver these two years, my relationship with AI moved through several stages:\n\nThe most valuable lesson is not that prompts are powerful or that coding agents are fast.\n\nIt is that useful AI systems depend on everything around the model:\n\nI remain an ordinary engineer.\n\nBut AI is now embedded in how I build applications, use company knowledge, record project decisions, and explore new subjects.\n\nI do not know which models or development tools will still be dominant 24 months from now.\n\nI do expect the distance between an idea and an implementation to keep shrinking.\n\nThe difficult part will remain deciding which ideas deserve to be implemented, designing systems that can be trusted, and taking responsibility for what the agents produce.\n\nAfter writing this retrospective by the ocean, I should probably continue taking the morning off.\n\nBut I am already thinking about opening Claude Code again.", "url": "https://wpnews.pro/news/from-prompting-chatgpt-to-orchestrating-ai-agents-two-years-as-an-ordinary", "canonical_source": "https://dev.to/timetxt/from-prompting-chatgpt-to-orchestrating-ai-agents-two-years-as-an-ordinary-engineer-1li7", "published_at": "2026-06-21 05:41:51+00:00", "updated_at": "2026-06-21 06:37:20.366705+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-agents", "developer-tools", "ai-products"], "entities": ["ChatGPT", "Cursor", "Andrew Ng", "Microsoft", "SwiftUI", "MCP"], "alternates": {"html": "https://wpnews.pro/news/from-prompting-chatgpt-to-orchestrating-ai-agents-two-years-as-an-ordinary", "markdown": "https://wpnews.pro/news/from-prompting-chatgpt-to-orchestrating-ai-agents-two-years-as-an-ordinary.md", "text": "https://wpnews.pro/news/from-prompting-chatgpt-to-orchestrating-ai-agents-two-years-as-an-ordinary.txt", "jsonld": "https://wpnews.pro/news/from-prompting-chatgpt-to-orchestrating-ai-agents-two-years-as-an-ordinary.jsonld"}}