So.. I need a Mandalorian helmet for this one .. wait .. I HAVE one! 🤪
You know the line they keep repeating: “this is the way“. And the funny thing about Mandalorians is .. they never actually question it. It’s “creed”. You do it because.. well .. that’s the way. End of discussion.
And lately I caught myself doing exactly that. We built a way. I’m pushing it on my team. And I’m honestly not 100% sure that .. “this is the way” 🙈
Let me explain..
what we did
The past months we’ve been busy getting our whole team onto agentic development. Not “someday”. Not “when you feel like it”. Now! Asap!
What started as “waldo’s pet project” turned into something I’m evolving together with a few leads in my team. And we built stuff. Our BC company guidelines .. but as a set of agents. And then a little VSCode extension (our iFacto Playbook) that just drops all of that straight into the developer’s lap. Open VSCode .. the agents are there, the guidelines are there, the MCP’s installed, skillset present .. good to go.
And here’s the thing I really want to be honest about: our whole intention was to make it as approachable as possible. We didn’t want everyone having to figure stuff out. No death-by-setup before you even write a line of code. No “first read these 14 docs and configure these 6 things yourself”. Just .. a wizard to make it work. Out of the box. As easy as at all possible.
And we were kind of proud of that, to be honest 😉
But…
By taking away “all” the friction .. did we also take away the “learning”?
Because that friction .. that’s usually exactly where you figure out how this stuff actually “works”. You wire it together yourself, you break it, you fix it .. and that’s where the understanding sits. And we just .. removed it.
So maybe – by making it so easy – we robbed “the new developer” (the groku .. 😉) of the chance to learn the skills they actually should know.
(if this sounds familiar .. it’s basically the same nerve I hit in “I built the tool .. but forgot the skill“. Apparently it’s somehow rooted in me.. 🤪)
Then .. a room full of peers
Last week I had the opportunity to sit down with a bunch of peers in Lisbon. Fellow CTO’s .. all of us fighting the same beast: AI we have to adopt ourselves, get genuinely good at, and be able to offer to our customers. You get the idea…
We went around the room, and everybody shared how they tackle AI in their company. And listening to it .. I was one of the odd ones, I guess .. 🙈.
Most of them leaned the same way: give people the tools, set a direction, let it grow organically. And there’s me going “nope .. we built the whole harness and basically removed the choice” 🤷
People jokingly called it “the waldo way” – hence the title of the post ;-).
So when I shared how we did it .. it didn’t fully land ..
Hand developers a finished harness, and yes – you get fast and uniform adoption. But you might rob them of the most valuable skill of all: building and evolving their own agentic harness. You make them good at your way .. instead of good at finding their way.
Yeah ..
but .. here’s the thing
It does work ..
Nobody complains. Like .. nobody. At least not to me 🤪. And the adoption was fast – way faster than the organic, let-it-grow route. Everybody on the same level, in no time.
And here’s the part I keep coming back to: those same peers pushing back on me .. a bunch of them were telling me they’re struggling with exactly that .. adoption. People using the tools the “wrong” way (although these days – are we even able to say what is the right way?). People just .. vibe coding 🙈. The exact mess “the waldo way” kind of .. avoids.
So the trade is real, and it cuts both ways. We traded depth-of-ownership for speed-and-consistency. They kept the ownership .. and got slow, uneven, vibe-coded adoption.
How did my teacher call it again .. “double ethical ambiguity”? 🤔
so .. are we right or wrong?
Honestly? I don’t know 🤷. And I’m not going to pretend I do.
Maybe we’re building dependency instead of capability. Maybe we made a bunch of devs who are great at “our” way and a bit lost the moment they have to think for themselves.
Or .. maybe “make it easy now, let them grow into evolving it later” is just a perfectly fine order of things. You can’t evolve a harness you’ve never even touched, right? Get them hooked first .. then hand the friction back, on purpose. It’s where I’m at now. Maybe we’re just simply giving people a head start .. 🤔. May be this a glass-half-full way to look at it .. 🤔.
Or maybe it’s not even a principle .. maybe it’s just a team-maturity thing, and the honest answer is “it depends”. Which is the most boring answer in the world .. but probably also the most true one .. 🙈
so what do YOU do?
And that’s actually why I’m writing this. Not to tell you we cracked it – we clearly didn’t.
So I’m asking you: do you hand your devs a ready-made harness? Or do you make them build their own? Where’s the line between removing friction and removing the lesson? And if you’ve figured out the magic middle .. please, comment .. I’d love to know ;-).
This is the way .. or is it? 🤷
Loading ...
3 comments
I’ve had the same thought. I’ve been programming for over 50 years. There is no substitute for understanding the code, and the only way to really understand the code is to write it. That said, a couple of weeks ago I asked Claude to “rewrite this so it runs in the task scheduler”. Instead of spending an hour figuring this out, I spent two minutes watching Claude knock it out. The code was written and I learned something. So, like the King Fu master, paint the fence until you don’t need to. Another point is, AI takes code from the code we’ve written, so if we stop writing code the code will stop evolving. Then again, 70 years ago coders were writing in Assembly Language and that has not evolved nor needed to. Or should it?
I love the line about death-by-setup. As a programmer at a customer, it’s been tough moving from C/AL to AL The main friction is learning all the tools. And the frustration is the number of assumptions under most of the docs- from MS or the community.
First time I installed VSCode, the doc neglected to tell me git was a separate install. And don’t get me started on ALL the MS pieces you need to understand on the road to a functional BC system…..
I so appreciate the community and their willingness to spend time writing helpful pieces. But I really need folks like Jeremy V who will put together a multi part, hours long training on a specific piece. Getting it all together is tough.
I look at Github and I feel like the owner of a Leatherman who only uses the pliers. So many tools. So many folks talking about all the cool stuff they do with it. So little time to explore that along with all the other pieces.
So, I like your approach. I started on my BC journey about the time Steve Endow started his learning AL coding YouTube series. I learned a LOT but it was not comprehensive- he was learning as part of the series. I wish there were a better setup experience. But that was also fairly early in the AL-Go days (and AL-Go itself is a great help/tool). I think I deleted the whole VSCode setup and started over three times. I’m glad I could keep the code that I had managed to cobble together as I went through this learning curve.
That said, it frustrates me when something changes (a password expired and was reset, a MS service authorization that expires) and I don’t remember how I set it up two years ago, where to even look, and when I find it, how to make it work again.
Sorry for the rambling message. I want all the benefit of your fully setup harness, but I see the need for the learning. But, if I were managing a team that had to put out code, I would definitely lean your way. Get devs to a place where they can be productive, then introduce learning experiences (escape rooms) along the way.
eey Waldo,
Same here, We started half a year ago, creating agents, Instructions, skills. Flows through these agents.
Instructions changing to skills. And a way of distributing it to all developers by a click on a button.
It helps amazing well for general adoption. It does not work for me, for me it does, what did you ask then? because everybody has the same basic set, its easy to compare ways of working, Now like 6 months later, we are opening up for our developers to start creating there own Skills for our ‘package’ to share, why? because they ask themselfs.
So after some time when they have adopted ‘the way”.. they feel the space to start enhancing themselfs.
And now we are going to change to ‘our way’, opening up and workshops how to..