If you care about engineering, AI has put you in an awkward spot. Either you've refused it and you're watching everyone else ship faster than you, or you've used it and watched the output drift toward something you wouldn't have written yourself. I've spent the last several months working through this, mostly through building Flow, and I want to share where I've landed.
When I started, I thought the work was mostly about giving AI better knowledge. AdonisJS is rich and specific, so it seemed reasonable that if I packaged the docs and conventions well, the output would naturally be better. I built in that direction for a while. The results were okay, sometimes good, but never consistent.
What I came to is that knowledge alone isn't enough. AI doesn't just need to know about AdonisJS, it needs to be told how to engineer with it. The patterns, the decisions, the tradeoffs. The things that years of writing code in a certain way teach you to do without thinking.
None of that lives in documentation. It lives in your head, and if you want AI to produce code that reflects it, you have to get it out of your head and into the system.
That realisation is shaping Flow now. Less a knowledge layer, more an encoded version of how I actually engineer in AdonisJS. Let me make that concrete with a few of the skills I'm building.
-
Feature implementation: This skill encodes how I break down feature work in AdonisJS. What goes in the controller and what doesn't. What belongs in a service. Where side effects live. How to structure the boundaries so the code stays understandable six months later. Most AI output skips this thinking entirely and dumps logic wherever it first feels convenient. The skill makes AI do the breakdown the way I'd do it.
-
TDD: AI is genuinely bad at tests. It optimises for green. It writes tests that pass without actually testing the system underneath. Getting AI to do TDD properly, where the test drives the design and actually exercises the thing it claims to, takes real work. The skill encodes that work, so that when you ask Flow to build something test-first, the tests are the kind you'd have written yourself, not the kind that just happen to be green.
-
Cruddy controllers: I've spent most of my career keeping controllers to the seven resourceful methods, and there's a real process behind it. You decide what's a resource, when an action wants to become its own controller instead of a custom method, when something belongs at a different level entirely. That decision-making is now a skill. It moves the brainstorming to AI, so the controllers Flow produces stay disciplined the way mine do.
-
Roles, not helpers: I've spent years building systems around roles instead of reaching for helper functions every time something gets reused. There's a worldview behind that choice and it changes the shape of the codebase significantly. That's a skill too.
If you notice the pattern across these, it's the same pattern. Every skill is taking a piece of engineering knowledge I've built up over years and translating it into something AI can follow. I'm not handing AI a framework and hoping. I'm handing it the way I think.
That's the part that matters. You'll still need an eye on what comes out. AI isn't going to be left alone in the driver's seat. But the heavy lifting, the part where you'd otherwise be re-explaining your principles every session, that's what the skills are for.
A note on the architecture
Flow is layered, and the shape is roughly this. Layer one is framework knowledge, compressed into cookbook and instructional documents the AI can read on demand. Layer two is the engineering skills I described above, the encoded patterns and processes. Layer three is runbooks, pre-built features that AI delivers by following a prescribed set of steps end to end.
The architecture has shifted a few times internally already, and I wouldn't be surprised if it shifts a little more before it's final. But the layering is the part I'm confident in. Knowledge sits underneath, engineering thinking sits on top of it, and runbooks orchestrate both for specific outcomes.
What to expect
Flow is not going to build your application while you sleep. It's not going to turn a one-line prompt into a production system. The codebases you maintain need to be understood by you in six months, extended by your team, debugged at two in the morning. Code generated without underlying coherence looks fine on ship day and becomes a problem later, in the part of the work nobody posts demos of.
What Flow is going to do is make AI a reliable collaborator on the work you were already doing. The code it produces will follow the framework's patterns and reflect the engineering choices I'd make. You'll bring your own judgement, override what doesn't fit, and shape it for your codebase. But the defaults will be opinionated, because they reflect how I think AdonisJS wants to be used. As I open up the skills and show how they're built, those opinions will become much clearer.
I'm still a couple of months out from the version of Flow I want you to actually use on real work. I'm sharing this now because when Flow lands, I'd rather you arrive with the right mental model than the one the wider AI conversation has trained you to expect.
More soon.