We Learned to Code So That Others Could Type a Prompt

I smiled when I saw the post. "Can't believe I coded by hand for 15 years... only to end up typing 'fix this' into a chat box and watching an agent do the work." Many engineers can relate. But it also made me reflect on where I started my career — and what those years were actually worth.

For almost 7 years at i2c, I worked on mission-critical payment processing systems. This was long before AI coding assistants, DevOps platforms, Kubernetes, cloud-native architectures, or infrastructure as code became mainstream. It was a different world. And in many ways, a more rigorous one.

The i2c Years: What That World Actually Looked Like

There was no DevOps team. We had SCM and Service Delivery. Infrastructure was managed by strong network and data centre teams. F5 load balancers were part of our daily conversations — not abstractions in a YAML file, but real systems we understood and reasoned about.

Applications were built in pure Java. Frameworks were largely forbidden — not out of dogma, but because performance, predictability, and control mattered when you were processing financial transactions at scale. Every dependency was a liability. Every abstraction had a cost you had to justify.

ISO 8583 wasn't just a standard. It was the language of payments — a protocol we read, debugged, and extended. PCI-DSS compliance wasn't an annual checkbox. It influenced every design decision, every data handling choice, every logging call. Audits were not occasional events. They were part of the culture.

The engineering culture was equally deliberate:

• Capacity planning, throughput, failover, and resilience were discussed every day — not as architectural ideals, but as operational realities.
• Manual testing was the norm, and we spent years transforming it into automated testing — one suite at a time, fighting for every percentage point of coverage.
• Knowledge transfer and mentoring were critical because the domain was specialised and mistakes could be expensive. A bug in a payment switch doesn't surface in a staging environment. It surfaces in production. With real money.
• Hiring standards were intentionally high. Quality mattered — not as a policy, but as a survival instinct.
• Object-Oriented Programming wasn't a chapter in a book. It was how we thought every single day.

No builds on Monday. No builds on Friday.

Production changes happened on carefully selected days because stability mattered more than speed. It wasn't Agile. It wasn't fashionable. It was a blend of disciplined waterfall planning, rapid application development, rigorous reviews, and operational excellence. And it worked.

What Fascinates Me About the AI Era

AI can generate code in seconds that would have taken hours or days when I started. That is genuinely remarkable. I don't say that dismissively — I say it with awe. The acceleration is real. The productivity unlock is real. Agents that can write tests, scaffold services, suggest refactors, and explain stack traces are not toys. They are force multipliers.

And yes — sometimes the right move really is to type "fix this" and watch it work.

But the deeper realisation I keep coming back to is this: the value of those foundational years was never memorising syntax.

The Mental Models That Remain

The value was in learning how systems actually fail under load. Why resilience isn't a feature you add at the end — it's a property you design in from the start. How to reason about latency in a distributed chain where each hop compounds. How to debug a production incident at 2 AM with incomplete logs and a business on the line.

What AI Cannot Prompt Away

AI can write code. But understanding why a payment should be authorised, declined, retried, reconciled, encrypted, audited, or routed a certain way still requires engineering judgment. It requires domain knowledge built over years of reading failure logs, sitting in audit rooms, debugging ISO 8583 fields at the byte level, and shipping systems where a mistake costs real people real money.

The prompt is only as good as the judgment behind it. When an AI generates a payment retry mechanism, someone still needs to know whether that retry is idempotent. When it scaffolds an encryption layer, someone still needs to know whether the key management model is compliant. When it suggests a caching strategy, someone still needs to know whether stale data in that context is a performance trade-off or a financial risk.

Those questions cannot be answered by typing "fix this."

In many ways, the engineers who spent years building payment switches, transaction processors, and high-throughput systems are uniquely positioned for the AI era — not because we type faster, but because we understand the systems behind the prompts. We know what to ask for. We know what to verify. We know what the AI doesn't know it doesn't know.

The Principles Have Not Changed

Those years were not wasted. They built the mental models that help us evaluate what AI produces today. The engineers who once debated JVM tuning parameters, F5 persistence profiles, and ISO 8583 bitmap structures are now the engineers who can look at AI-generated code and say — with confidence — whether it will hold under production load.

A special note of gratitude to my former colleagues, mentors, architects, engineers, testers, service delivery teams, and leaders at i2c. Thank you for teaching me engineering discipline, operational excellence, and respect for building systems where reliability is not a feature — it is the product.