The Last Class Taught Without AI
Act 1: Navy SEAL Training for Founders
The Founder Institute describes itself as the world's largest pre-seed startup accelerator.
What it doesn't tell you is that it's Navy SEAL training for founders.
I joined the first Sydney cohort in 2011. Tech lover. Business thinker. Total outsider when it came to actually building anything. I knew what I wanted to build. I could see the systems clearly. I understood how products worked, how markets worked, how the people who use technology actually behave. What I couldn't do was make the machine execute the vision.
The Founder Institute doesn't care about that. It cares about whether you can operate under sustained, compounding pressure, whether the thing you think you want to build is still standing after you've been stress-tested for weeks by people who have seen a thousand founders fold. It was one of the most intense, formative, genuinely valuable experiences of my professional life.
I loved every minute of it.
Then I had a mental breakdown.
Not a single cause. The intensity was the primary driver, redlining an engine past its rated capacity until something gives. But there was a second pressure running underneath it, quieter and more persistent: the frustration of a high-latency interface that couldn't keep up with the speed of the thinking.
The syntax problem. Not comprehension. I understood what code was supposed to do. The issue was the gap between the system I could see clearly in my head and the characters I was typing on a keyboard. It felt like being handed a chisel and told to build a cathedral, technically possible, but not at the speed the mind was demanding. Every compile cycle, every debug loop, every syntax error was a friction point between the architecture in my head and the implementation on the screen. That friction compounds. Over weeks of sustained intensity, it became another form of redlining.
So I filed both. Not abandoned. Filed. There would be a time for this. It wasn't now.
The breakdown was the system telling me it needed a maintenance window. I gave it one. And I went back to what did match the pace: environments where the feedback is immediate, the system is human-scale, and the gap between decision and consequence is measured in seconds rather than compilation cycles.
I went back to the floor.
Act 2: Twenty Years at the Interface
If you've read the first piece in this series, From Dishes to Clatter, you already know what those twenty years produced. The lessons from the restaurant pass and the festival field are documented there and I won't repeat them here.
What I will say is this: those years were not a detour from the technical path. They were a deeper education in the same subject.
Every complex live event I ran was a distributed systems problem. Every high-pressure service I managed was an exercise in interface design, error handling, and graceful degradation. Every season of large-scale productions was a masterclass in what happens when independent complex functions have to compose in real time toward a single coherent goal, and what it costs when the coordination layer fails.
The vocabulary was different. The principles were identical.
By the time I sat down in a formal computer science classroom for the first time at 43, I had been studying the same subject for two decades. I just hadn't known that was what I was doing.
Twenty years of operational experience at the highest level of complexity. Not theory. Not simulation. The real thing, with real consequences, in front of real audiences, with no rollback.
That is the foundation everything else was built on.
Act 3: Five Years in the Research
Somewhere in the middle of those twenty years, I found Cardano.
Not through a price chart. Not through a friend who told me it was going to the moon. Through the research.
Cardano entered the ecosystem differently from almost everything else that was happening in that space at the time. While others were moving fast and breaking things, shipping protocols, forking chains, making promises that the technology couldn't yet keep, Cardano was publishing peer-reviewed academic papers and building from first principles. Ouroboros. The extended UTXO model. A formal approach to smart contract verification. A genuine attempt to build decentralised governance infrastructure that could actually govern something.
I was drawn in by three things specifically:
Transparency. Everything was in the open. The research, the rationale, the trade-offs. No black boxes. No trust-us-it-works. Auditable by design.
Rigour. The peer-review process. The academic partnerships. The insistence on formal verification before deployment. The willingness to be slow in order to be correct. In an ecosystem defined by speed and hype, this was a profound differentiator.
The governance vision. Cardano was not just building a cryptocurrency. It was building decentralised infrastructure for human coordination, a layer on which governance, identity, and verifiable systems could run without requiring trust in any central authority. That vision resonated with everything I had learned about how complex systems actually work and why centralised points of control are always, eventually, failure points.
I became a private round investor in early DeFi on Cardano. Not speculation. Conviction. Skin in the game as a signal of belief in the architecture, not a bet on the price.
And I studied. Five years of following the research. Learning distributed systems and security at a depth that formal education hadn't given me yet. Understanding consensus mechanisms, cryptographic primitives, smart contract security, the economics of decentralised systems. The Cardano ecosystem was, in practice, a graduate-level education in the systems I wanted to build: open, rigorous, and free.
By the time I enrolled in a formal programme, I had five years of that background already in place. The formal education would give me the implementation layer. The research had already given me the architectural thinking.
Act 4: The Decision
At some point in your forties, if you have been paying attention, you arrive at a specific kind of clarity.
You know what you are good at. You know what you are not good at. You know which environments bring out the best of what you have and which ones drain it for no return. You know the difference between work that is hard because it is worth doing and work that is hard because the people around you are making it harder than it needs to be.
I had spent twenty years running complex operations at the highest level. I had done it well. And I had spent the last years of that career increasingly aware that the limiting factor was not the complexity of the systems. It was the quality of the decisions being made above me by people who understood less about those systems than I did.
There is a particular kind of frustration that comes from being the person in the room who can see most clearly what needs to happen and not being the person with the authority to make it happen. I had managed that frustration productively for a long time. Eventually I stopped being able to.
I couldn't work for idiots anymore.
So I retired. I was 43.
Not a crisis. Not a breakdown. Not a dramatic exit. A clean, deliberate, self-aware decision made from a position of strength. The operational equivalent of taking a function offline to fix it properly rather than patching it live. You do not perform emergency surgery in a running production environment. You bring the system down, do the work correctly, and bring it back up better than it was.
The axe needed sharpening. I had the time, the resources, and the clarity to do it properly. So that is what I did.
I enrolled in a developer programme at Medieinstitutet in Sweden. Full stack. From syntax. No shortcuts.
Act 5: The Last Classical Education
The programme started with a rule: no AI tools.
This was late 2024. The tools existed. GitHub Copilot was already mainstream. Claude was already in wide use. The AI-assisted development wave was already well underway. And the curriculum was deliberately, explicitly, not engaging with any of it.
Learn the fundamentals first. Understand what the machine is actually doing before you ask something else to do it for you. Know what correct looks like before you can evaluate whether the output is correct.
I agreed with this completely.
So I learned syntax the slow way. Variables, functions, loops, recursion. Data structures from the ground up. Algorithms from first principles. Test-driven development: write the test first, watch it fail, write the code, watch it pass. Clean code. DRY. KISS. SOLID. The classical principles that have governed good software development for decades, taught without the safety net of an AI that would catch your mistakes before you understood why they were mistakes.
It was the right way to learn. It was also, I will be honest, not fast. The syntax still didn't move at the speed my brain wanted. But this time I had the patience for it, because I understood what I was building toward. The foundation was not the destination. It was the thing that would make everything after it trustworthy.
Then the AI tools started appearing alongside the curriculum. Not in the coursework, outside it. In the ecosystem. In the tools other students were quietly starting to use. In the workflow conversations happening on Discord and Reddit and in the corridors between classes.
And I watched something happen that I recognised immediately from twenty years of operational experience:
People started cutting corners.
Not maliciously. Not lazily. The tools were genuinely useful and the shortcuts were genuinely tempting. But the pattern was familiar, the same pattern that produces a station that doesn't get wiped at 3am because no one important is watching.
I saw where it led. I took over a project that had been built this way, prompt by prompt, feature by feature, with no governing principles and no meaningful architecture underneath. The demo ran. It looked, on the surface, like something had been built. You could click through it. The happy path worked.
The deeper I went, the clearer it became.
This had not been built. It had been generated. Every function did approximately the right thing under approximately the right conditions. Nothing had been designed for the edges. Nothing had been tested against failure. The architecture was whatever shape the AI had defaulted to when given a sequence of prompts with no one governing the principles behind them. It was a facade: convincing from the outside, structurally empty behind it.
Putting it into production would have been like opening a festival with no site operations manual, no briefed crew, and no comms infrastructure, because the load-in looked fine from the car park.
I rebuilt it from scratch. Not because I wanted to. Because there was no other option.
You cannot patch a foundation. You can only replace it.
That project is why the first file in every Ydun project is AGENTS.md. Written before the first line of code. Because a project without governing principles isn't a project. It's a prompt history.
I made a different choice from the start.
I kept the classical principles. All of them. TDD, documentation first, clean code, KISS, DRY, no shortcuts. And I applied them to the AI tools, not as a constraint on the tools, but as a governance layer for them. The same way the site operations manual governs the festival functions without interfering with their autonomy.
If the AI was going to be a function in my development system, it was going to operate within the same principles as every other function. It was going to get a proper briefing. Its outputs were going to be validated. The handoffs were going to be clean. The documentation was going to exist before the code.
The speed was still there. The shortcuts were not.
Act 6: Speeding Up the Rigour Loop
Here is what I noticed.
Every principle that makes classical software development trustworthy also makes AI-assisted development trustworthy: TDD, documentation first, clean architecture, explicit error handling, no magic. Not because the AI needs to be constrained, but because the principles exist to produce reliable output from any system operating under uncertainty. The AI is a system operating under uncertainty. The principles apply.
The difference is speed. Classical development with rigorous principles is slow because the human is doing everything. AI-assisted development with the same rigorous principles is fast because the AI is doing the implementation work while the human governs the principles.
The rigour is not the bottleneck. The rigour is the thing that makes the speed safe.
I didn't invent this insight. Cardano had been demonstrating it for years: that you could be both rigorous and productive, that peer review and formal verification were not obstacles to shipping but conditions for shipping things worth keeping. I just applied the same logic to a terminal.
The methodology that emerged from eighteen months of daily use, across real projects spanning decentralised systems, web development, desktop applications, cryptography, and cross-platform mobile, is documented at docs.ydun.io. Jimmy's Workflow. The 11 Core Principles. AGENTS.md. The session continuity system. The multi-agent coordination patterns. The prompt frameworks.
It is open source. All of it. Free to use, free to fork, free to improve.
Not as a product. Not as a pitch. As infrastructure.
Because that is what Cardano taught me about how knowledge should move: transparently, in the open, auditable by anyone, owned by no one. If the methodology is sound, it should be able to withstand scrutiny. If it helps other developers build better systems, it should be available to them. If it needs to improve, the people using it should be able to contribute to that improvement.
The student who couldn't make syntax move fast enough at Founder Institute Sydney in 2011 now has a methodology that helps developers move faster without losing the rigour that makes speed safe.
That is not an accident. That is what happens when you file a problem instead of abandoning it, and come back to it thirteen years later with the right tools, the right foundation, and the clarity that comes from having sharpened the axe properly.
I didn't run off and build a product. I focused on learning the tools and the trade first. The methodology is what you find at the other end of that discipline.
What Comes Next
This is the second piece in The Long Way Round. The first, From Dishes to Clatter, covers the operational philosophy. This one covers the journey that produced it.
The pieces that follow go deeper into the methodology itself: the specific templates, the workflow phases, the principles in practice, and the findings from eighteen months of building in production with AI as a genuine development partner.
The docs are at docs.ydun.io. Everything there is free. Start with the Philosophy page if you want to understand why the methodology looks the way it does. Start with the Getting Started guide if you want to use it today.
If the arc resonates, the outsider who took the long way round and found something worth sharing at the other end, follow along.