Category: Uncategorized

At work, many people are being given an initiative to learn AI and innovate with it. One person brilliantly took a simple assessment and made it into her own web app. Another person took the output of several assessments and had Claude merge them into one super assessment result.

I thought both were brilliant and wanted to take it another step further … of merging these related ideas, using Agentic Engineering, to build an assessment engine that merges the assessment concepts of DiSC, Myers-Briggs, Clifton Strengths and Working Genius. There should be some overlap, and Generative AI should find it…

Check out the result: your friendly AI-Robotic PERSONAL BRAND ASSESSMENT

But what I want to harp on a little is something YouTuber Alberta Tech addressed in her video “Do Google engineers actually vibe code?“.

In her video she talks about the differences between vibe coding and agentic engineering.

Agentic Engineering is “Engineering using agentic AI systems.” It asks, “How do I use AI to build systems that can reliably do the work I design it to do, and can I add to that some unit tests and continuous integration?”

Vibe Coding is “Using AI to write code that I might not understand but seems to work.” It asks, “How quickly can I build something useful with AI helping me write the code (that I don’t need to understand, update, maintain or manage by hand)?”

Aspect	Agentic Engineering	Vibe Coding
Primary Goal	Build reliable autonomous systems that accomplish business tasks	Rapidly create software by collaborating with AI
Success Metric	Task completion, accuracy, reliability, ROI	Speed, creativity, working prototypes
Planning	Explicit workflows, orchestration, state management	Minimal upfront planning; iterate as ideas emerge
Human Role	Designer, supervisor, evaluator, governor	Co-creator, experimenter, director
AI Role	Autonomous worker that can plan and act	Coding assistant that generates code on demand
Complexity	Often involves multiple agents, tools, APIs, and memory	Usually focused on a single application or feature
Failure Cost	Can affect operations, customers, or business processes	Usually limited to bugs, rework, or technical debt
Testing & Validation	Formal evaluation, monitoring, guardrails, observability	Often “run it and see if it works” with lighter testing
Similarity: Iterative Development	Iteration is structured and measured against objectives	Iteration is intuitive and driven by exploration
Similarity: Heavy AI Usage	AI performs delegated work within engineered constraints	AI accelerates coding through conversational collaboration

“Agentic Engineer” is one of those new roles that has evolved from the existence of AI. It fits along the same lines as “AI Workflow Architect” and “Human-AI Operations Manager”.

For the past 25 years we had IntelliSense built in a VisualStudio.NET IDE. Some loved it. Others hated it. But over the years from 2001 and 2021 it got better and mind-melded itself as part of coding life. And actually, around 2017, Microsoft had expanded it to IntelliCode.

Vibe coding was coined in 2025 and took off for a few months, but it was effectively … bad.

Bad at unit testing – it would create false positives. Bad maintainability – it would create more technical debt. Bad coding practices – it would cause patchwork code bases (i.e. spaghetti code) . Bad security – it would hardcode secrets and introduce bugs that allowed injection attacks. But most grievous of all it changed the behavior of coders and introduced…

The Erosion of Developer Skills

The over-reliance of AI caused a dumbing down of junior and mid-level software engineers. They would gloss over the hundreds of lines of newly generated AI slop and not take the time to do a thorough code-review to determine if it broke LEAN design practices or if it disrupted the orthogonality of the existing system – i.e. introduced new code that unintentionally affects other code. Juniors typically don’t look for this in their code on a good day – but for AI to offer code slop made it all much worse.

The Time-Suck of Senior Developers

Which takes Alberta (and many of us senior-level engineers) into problems that hit closer to home. We are the gatekeepers responsible for making sure new code is following the design patterns and is bug-free and contains unit testing code-coverage to prove it. When hundreds or even thousands of new lines of code … or so much worse … lines of changed code get submitted for approval, our weekends are shot. There’s no way we can go through all that… so we just hit the “reject” button and walk over to the junior’s desk to have a talk… which doesn’t do much good because the manager just had a talk with them earlier that day and ordered he (or she) use more AI to vibe code faster.

Vibe Coding Isn’t Great, But Agentic Engineering Has Promise

Now we can create agents that do some gatekeeping for us (senior folks). We can give full instructions on what tests to see, what coding practices to adhere to, and what design patterns to implement across the code to make it consistent, clean and coherent. When people check in slop, the agents can at least do a quick check and flag if anything looks off … like more than 15 lines of code change (I’m not naming who, but it was a manager in my past who really didn’t know better). So it now becomes this Agentic Bureau of Acceptable Code As-a Service…

That’s right! I’m cracking out an ABACAS. I want to bring history full circle!

Now go try that PERSONAL BRAND ASSESSMENT … it actually is pretty useful!

Why we use the term “Tokens” with AI today… before AI, software engineers used assemblers and compilers. The most common tools are LEX and YACC. LEX would take parts of a written language (specifically a programming language) and convert them into “tokens” which then went to YACC to be processed for context.

But even before the 1970’s (when LEX was created at Bell Labs) the term “token” was used as a place-holder or representation of something greater … as in a “token of affection”. The term “token” dates back to old English tæcen, meaning a sign, mark, symbol or indication but had been more historically used in Germanic languages (Zeichen) which means “sign”… more on that in a bit.

Long before we used it in computers, in the middle ages, people would give brooches and rings to loved ones as symbols of commitment (where we got the custom of the engagement ring) . One common trend at the time, for those who couldn’t afford brooches and rings, was to bend or engrave a coin to give as a gift to represented a value of something else. In the Old English tongue, during the Middle Ages, they didn’t have a name other than “a bent coin presented to my love” or “a pledge”. But in High-German of the middle ages, they would be called “Zeichen”. They were no longer spendable coins. As signs, they represented something specific and special to its giver and bearer.

So when you use a GPT today, even though computers can’t love, it was a lovely custom that over the centuries gave us the terminology we feed into it today.

In the last post, I briefly mentioned that having a purpose statement for the meeting could reduce the time it will take. That’s the focus aspect of planning, with the intent of staying on the predetermined topic and goal.

In our world, across the globe, no symbol is more ecumenically purposeful and meaningful than the bathroom sign. Everyone wants to know where it is in case they, or someone they know, needs it. That sign has a specific purpose, and is meaningful to a wide audience. This is what our meetings aspire to be. However…

There are different types of people who attend these meetings and each one will have a different goal. In a board meeting with treasurer, publicity, technical, administrative and secretarial staff present, you have each person interested in a different aspect of the meeting. Even stand-ups have a manager and sometimes a director attending along with developers and knowledge experts.

The purpose of the meeting should be distinct and focused. If everyone needs or wants to know the information that other departments provide, it should be stated what the expectations are. Perhaps the director wants to know how much a software upgrade costs and the developer wants to know if and when to expect that software to provide an estimated time of completion to the manager.

Often there are attendees who have little input and no interest in the rest of the meeting. The brief information they provide could be summed up in an email or a pre-recorded video presentation.

To make meetings more meaningful:

1. Think of what you can provide that others cannot.
   • It doesn’t have to be unique knowledge or abilities … it might be finding some time putting slides together when other members of the team cannot spare the time for it.
2. Consider if what you provide has interest to other attendees.
   • Put on a thinking cap and use your listening skills. Ask the other attendees if you’re unsure. Healthy teams want to improve the overall productivity and will be glad to help.
3. Think of what you’d like from the other attendees.
   • A favor to ask
   • Information
   • Opportunity request
4. Remember that these meetings are give and take.
   • Don’t spend too much time doing one or the other; Ideally, you want to sit on both sides. Otherwise there are better ways to achieve the goal than taking up other people’s time in meetings.

Meetings should be genuinely helpful in providing direction and cohesion to the team and its individuals. They are a critical element in the decision making process, and can be a form of team building. Making them more effective, impactful, timely, and meaningful saves money and frustration by increasing productivity and involvement.