Hello Blinky

Because my background is in electronics engineering, my "aha!" moment was deeply physical. I started out building breadboard hobby and university projects with the PIC16F877A, ATmega328P, Arduino, and ESP32 dev boards, displaying sensor data on seven-segment and LCD screens. Later, I did similar work professionally on larger embedded systems — utilising NI DAQ boards and the Renesas H8 series to read photodiode signals and run feedback loops actuating PZTs, air pumps, and various other hardware components.

One of the earliest thrills I recall was how quickly I could actuate a transducer — making an LED blink on a breadboard in exactly the pattern I told it to. It was getting a buzzer to beep on command. It was wiring a DHT11 sensor and reading temperature and humidity. It was an HC-SR04 ultrasonic proximity sensor telling a robot when to stop and turn.

Every one of those felt like magic — and the trick was that I could change the outcome by changing a few lines of code. Debug it, refine it, make the code as clean and maintainable as I could, and watch the physical world respond: a light blinks, a motor turns, a sensor reports back exactly what I told it to expect. That loop, from keystroke to blinking light, was intoxicating.

Now, if you spent your career building enterprise business software, a DHT11 sensor probably wasn't your catalyst. Your spark might have been a database query finally pulling back complex data in milliseconds, an automated email successfully hitting an inbox, or a dynamic dashboard instantly rendering financial trends for a client.

But look closely at both scenarios, because the underlying truth is identical.

Whether it was a transducer-based instrument or a mission-critical business application, the code was simply the bridge to get there. The true dopamine hit came from the output — the realisation that you had constructed a system that solved a real problem.

Back then, I never had to sit down and articulate this — I was too busy enjoying the process to stop and put words to it. But looking back now, I can be honest about what was really going on: the outcome was the main catalyst, but it wasn't the whole of it. Solid architecture, code clean enough to trust, a design that didn't fight me the tenth time I touched it — that was a real part of the joy too, not just a means I tolerated on the way to the outcome. But if I'm honest about why that craft mattered to me, it was in service of the loop: I wanted the code clean because clean code was what let me change the blink pattern with confidence, extend the feedback loop without breaking it, trust that the buzzer would still beep correctly after the tenth refactor. The craft was real, and it was genuinely satisfying in its own right — but it was satisfying largely because of what it made possible, not entirely independent of it. The transducer-based instrument — the thing that sensed, measured, actuated, responded — that was the product. The dashboard, the report, the email that landed — those were the products too. I was in love with building things that worked in the real world, and the architecture underneath was part of what made that love durable, not a separate thing I loved on its own terms. The end user, the product owner, never cared about the code at all — they cared about the outcome it produced. The code was just the language I used to negotiate with the hardware, the data, the business logic — whatever stood between an idea and its outcome — but it was a language I cared about speaking well, not just correctly.

I should be honest about where I sit on that spectrum, though, because plenty of developers sit further along it than I do. For some, the joy isn't craft-in-service-of-outcome the way it was for me — it's the writing itself, full stop: the flow state of a clean recursive solution, the satisfaction of an elegant one-liner, code as a form of expression that would still be worth doing even if nothing physical ever responded to it. That version of the joy is real too, and nothing here is meant to talk anyone out of it. What follows is about where the outcome-driven part of the joy goes when AI writes more of the syntax — which was the larger share of it for me, even if not the whole share. If your joy was always in the syntax itself, independent of what it produced, the honest answer is that AI does take something from you — not because the craft has become less valuable, but because there's simply less of that specific craft to do by hand. That's worth naming plainly rather than smoothing over.

Why This Distinction Matters Now

If AI is increasingly good at writing the code — and it is — then AI is encroaching on the means, not the end.

It's automating the translation layer between "what I want to happen" and "the lines of code that make it happen." That's a real and significant shift. But it's not the same as automating engineering. Engineering is the discipline of figuring out what needs to happen, why, under what constraints, and how you'll know it worked — and no amount of translation speed does that thinking for you. AI can help surface the gaps in a problem definition; it can't supply the judgement that decides what the definition should be.

So the fun isn't gone. It's just no longer located primarily in the syntax. It's moved upstream, into the harder and more human part of the job: figuring out what to build and specifying it precisely enough that it can actually get built — whether by a junior engineer, a senior engineer, or a model.

The Death of the "Vague" User Story

What AI is doing right now is automating the means to an end. It is streamlining the syntax and the boilerplate implementation, but it has not replaced the engineering.

However, because the implementation is moving to autonomous AI agents, the way we design systems has to change. For the last two decades, the software world has relied on Agile methodology, feeding developers a steady diet of bite-sized, deliberately flexible user stories (e.g., "As a user, I want to reset my password so that I can access my account").

Agile user stories were designed for humans. They left room for conversation, assumptions, and coarse-grained implementation details that a human developer would naturally figure out on the fly. To be fair to Agile, this was never really Agile's fault — vague requirements have always been a weakness teams lived with, papered over by a developer's judgment and a quick Slack message asking "wait, what did you mean here?" That safety net worked because a human was on the other end of the ambiguity, quietly resolving it through context and intuition.

Agentic coding doesn't create that weakness — it removes the safety net that used to catch it. An AI agent cannot operate effectively on a vague, iterative whim the way a human colleague can. Hand an autonomous coding agent a loose user story, and it won't ask a clarifying Slack question out of instinct; it will hallucinate the missing context, misalign with your broader architecture, or build a localised solution that breaks the rest of the codebase. The ambiguity was always there. What's changed is that it no longer gets absorbed quietly — it surfaces immediately, in code that looks right and behaves wrong in the one edge case that mattered.

Instead, we're seeing a resurgence in the need for detailed, complete system specification. To orchestrate AI agents, we must provide a tightly defined architectural blueprint up front — the exact state machine, the rigid API contracts, how the entire ecosystem connects — before the machine writes a single line. The bar for specificity has gone up significantly, not because AI introduced a new failure mode, but because it removed the human buffer that used to hide the old one.

Specification Is the New Coding

Writing a clear problem statement was always a skill. Now it's closer to a superpower. The developers who thrive in this next era won't be the ones who can produce a for-loop the fastest — they'll be the ones who can:

• Map out a complete, end-to-end system blueprint, with data structures and boundaries defined before a single line of code runs
• Decompose a fuzzy business or engineering problem into precise, testable requirements
• Anticipate edge cases before a single line of code is written
• Write specifications detailed enough that "translate this into code" is close to a mechanical last step
• Understand how different components — physical hardware sensors, cloud APIs, whatever the system touches — interact to form a dependable, unified product
• Still understand the code well enough to know when the machine got it wrong

That last point deserves more weight than a single bullet, because it's where this argument has a real blind spot if I don't address it directly — and because "specification is the new coding" is only true if the person writing the specification stays sharp enough to know when the machine got it wrong.

The Risk in My Own Argument — and What It Means to Teach

If specification and system design are where the real work now lives, what happens to the developer who hasn't earned that judgement yet? The instinct to spot a bad edge case, to know a specification is precise "enough," to sense when an architecture will crack under load — none of that comes from reading about systems thinking. It comes from having personally wrestled with a broken loop at 2 a.m., and more fundamentally, from actually knowing the language, the data structures, the algorithms, and the design patterns well enough to have an opinion. You cannot judge whether an AI picked the right data structure if you don't know what a Dictionary buys you over a List. You cannot tell a repository that's earning its keep from one that's just unnecessary indirection if you've never had to reason about coupling yourself. That knowledge doesn't become optional just because AI can produce the syntax faster than you can — it's the entire basis on which you're qualified to review what AI produces, and the only thing standing between a tight specification and a black box you can no longer verify. Junior developers still need to learn the language, the structures, the algorithms, and the patterns properly, and write real code with them, badly at first, before any of the upstream skills mean anything. The goal isn't to protect them from AI; it's to make sure nobody graduates straight to writing specifications for a system built out of concepts they've never personally understood.

This changes what we owe to people learning to build things today. We used to teach "learn to code" as if syntax fluency was the finish line. It was never the finish line — it was the entry fee, and it still is. What's different is what comes after it. What we actually need to teach, on top of that foundation, is:

• The fundamentals, properly — the language itself, data structures, algorithms, and design patterns, learned by writing and breaking real code, not by reading AI-generated code and nodding along
• Problem framing — the discipline of asking what's really being solved and for whom
• Specification writing — for humans and machines alike, with a level of precision that used to be optional
• Systems thinking — understanding how the pieces (hardware, software, data, people) fit together
• Judgement — knowing when the output is good enough, and when it's dangerously not, which itself depends on still being able to read the output closely

None of this is new advice, exactly. It's the advice good engineers have always given. What's new is that it's no longer optional context — it's the actual job, sitting on top of foundations that still have to be built the old way first.

So, Has AI Taken the Fun Out of It?

Not for me. If anything, AI has clarified what the fun actually was — and sharpened what the craft actually demands.

I didn't fall in love with semicolons and curly braces on their own terms, but I didn't fall in love with pure outcome either. I fell in love with the moment a beeper beeped because I told it to — and with the code being clean enough that I trusted it, could extend it, could hand it to someone else without flinching. Both mattered, even if the outcome mattered more. That loop hasn't disappeared, and neither has the craft — it's just relocated. The architecture now has to be precise enough for a machine to execute faithfully; the specification has to be as clean and well-considered as the code used to be. The craft didn't shrink. It moved to where the thinking actually happens, and it still rests on the same foundation it always did — skipping that foundation is still the same mistake it always was.

The code was always the vehicle for the outcome, but building that vehicle well was never separate from the joy of the destination — it was part of it. Deciding what should happen, and why, and building it so it holds up, was always the real work. I just have a faster, more demanding way of doing both — and a real responsibility not to let anyone, including myself, get there without ever learning to drive.