I my last post I made it clear that (however much I might want to) I couldn’t avoid the current AI hype for agentic coding that everyone seems to be embracing and so I thought I’d give OpenAI’s Codex a whirl!

The first task I set it was to help me set up a new clean DEV environment for SPFx development and it surprisingly well – feel free to check out my initial foray at https://kaboodlesoftware.com/2026/06/14/getting-started-with-sharepoint-development-with-codex/

In that post I promised that I would try and build something useful with it and described how it went and that’s what this article is all about.

Life is what happens to you when you’re busy making other plans

…As John Lennon famously once said.

I had this idea for a useful extension to SharePoint sitting at the back of my mind for the best part of a decade, thinking that one day I’d get around to building it but could never quite find the time. Anyway, it seemed like a great little project to try out a new paradigm for me – build something useful and production ready without me writing a single line of code myself.

Moving right along

Before I go on the talk about how we (meaning Codex and I) got on, I think it would help if a revealed what it is that I wanted to build. I have named this thing K-Pulse and how about we chunk up the rest of this article into 3 sections, where I

• Summarise the requirements
• Show you what Codex and I built
• Close up by share my take on it all

Sounds like a plan?

K-Pulse Requirements

These requirements are self-generated – no customer gave me this shopping list.

However, lots of customers have (over the years) shared with me that K-Pulse is something that they would find useful. We can throw our requirements into 2 buckets.

• Functional: The features and capabilities that solution must provide and deliver, respectively.
• Non-Functional: This amounts to the set of constraints that are either outside of our control or which we chose to impose for some reason (costs, scalability, tech-sprawl, environment etc.)

Functional Requirements

• Build a messaging app which can display notification messages to users when they access a SharePoint Site.
• With a single click users must be able to:
  • Dismiss the message is a simple notification
  • Acknowledge the message when a formal acknowledgement record is required
• Only authorised users can create these messages.
• Messages must be targetable i.e. not all messages are necessarily displayed to all users
• Messages must be scoped – by that I mean they where they are created defines the pool of target users (in addition to the audience targeting mentions above) at the:
  • Site: Messages are only displayed when the user visits the site in which the message was created.
  • Hub: Messages created in a SharePoint hub site (or ancestor hub) might reach users in hub member sites
  • Home/Root: Messages created in the designated SharePoint home site, or the root site of the tenancy, might reach users on any site in the tenancy.
• Messages should be of specific types (Flash, Routine, Urgent etc.) but the list of message types must be configurable
• Messages can be defined with a time window such that message authors can set the
  • Release: The date and time from which the message will be shown
  • Expiry: The date and time after which the message will no longer be shown.
• The solution must track messages so managers can monitor user responses and gauge the effectiveness of their communications

Sounds easy enough right!

Look, there are more of these self-imposed functional requirements, but I’m sure you get the gist of it.

Before anyone starts shouting “Viva Announcements to me” – yes, I am aware of Microsoft’s attempt to build something like what I have just outlined but when you dig into it, Viva Announcements doesn’t come close. For starters you can only create Announcements from the tenancy Home Site so no hub or local site scoping like I just described. There’s no metrics either and very limited customisation options.

If only Microsoft would come and talk to me when they build these features, then they’d build stuff that would be far more useful!

Non-Functional Requirements

And the constraints (self-imposed of otherwise):

• I will build this using the latest (or near latest) version SharePoint Framework (SPFx) – why, because I want to start out on the latest and greatest 😊
• I’ll build this as an Application Customizer extension – why, because this allow me to add notifications on any site page without needing to explicitly add something to the page (as I would need to do with a web part solution).
• I want to user React for the UI and specifically I want to use the Microsoft Fluent set of controls – why, because that will allow me to build a solution that looks and feels as though it is a native part of SharePoint.
• It’s good to perform well and look cool – why, because it just does!
• The solution has got to work on mobile as well as it does on desktop – why, because that’s what users expect and deserve.
• If I am to provides metrics (how I think I want them) then I’m going to need to reach into the graph API – why, because the SPFx API does not have REST API hooks that allow me to text if users are members.
• I want this thing to be built to support a light and free Freemium version for unlicensed customers but unlock advances features (like the above-mentioned metrics) to encourage customers to part with some coin – why, because sharing is caring, but I believe that I should get some recompense for me efforts
• That means it needs to be license aware but fitting in with my product licensing framework – why, because I want a standardised way of managing customers and licenses.

Show us the money!

Ok, I know you are just itching to see this thing!

The above screenshot shows far more messages that would normally be case, but I wanted to show you the scoping feature. If you look closely, you will see that the UI is pulling messages from 3 different sources, namely the local site, a parent hub site (Regional Hub) and from the tenancy home site (KKiT Central)

Rather than me provide you with a whole bunch of screenshots and accompanying blurb, I encourage you to check out the short (3 minute) video, where my beautiful daughter Eleanor (or rather her AI generated avatar) will walk you through K-Pulse and how it works.

Show time!

I reckon that to churn out a production ready version of K-Pulse, where I cut all the code manually, would have taken me upward of 100 hours. I think Codex chopped that by about 60%, so that alone should be “Winner winner chicken dinner!” right?

Well, yes but I wouldn’t say the experience was all plain sailing. Here is a short list of my grumbles

React Class vs Functional Components

Personally, I’m not a fan of functional components (that’s probably because I am now too old to understand what the have to offer and TBH, I’m not really interested.

The thing is, SPFx (for legacy reason as that may be) uses React Class components and when Codex started adding functional components to the project, that mix-and-match approach just didn’t sit right with me. I am aware that this might be a personal failing on my part, but I just don’t care – if you want to get on a high-horse and preach manically about why I am so stupid – go for it!

Anyway, once I told Codex that I wanted class components only (and explained why) it replied with a cheerful “Fair enough” and did as it was told. Not sure that would have happened with real developers!

Refactoring

Codex started out by building the solution in a single .tsx file, which quickly bloated the file size way beyond the 2000 soft-limit – caused by all though functional components I didn’t want. Once I cottoned on to what it was doing, I ordered a mass refactoring of the solution where any my (class) components where neatly bound in their own files.

This refactoring took significant effort – possibly 3 hours or more – over several passes, but we got there and Codex promised to be more modular moving forward.

If you were using Codex to spit out a concept demonstrator, then I guess the megalithic file approach is sort of forgivable – though not really. I would expect even a junior developer to build stuff this way. I wasn’t that it didn’t work, it’s just that you had no chance of trying to figure out what was for what!

CSS and Inline Styles

Codex tended to push all style tweaks I wanted to CSS as overrides to the standard fluent components. What’s wrong with that I hear you say – it’s that best practice? Well best practice is only any good if it works and too often, in this case, it didn’t.

The problem is that Codex blindly assumed that the CSS changes it was making would be applied but failed to recognise that many of the Fluent components don’t like being told how to behave this way. They just override styles at a lower level so taking higher precedence. Fluent components provide a Styles attribute which is specifically designed for you to take style control when you need to, but you generally need to do this in-line for it to work.

Most of the time, Codex figured it out after a couple of attempts, but it really struggled with the styling in of the Fluent Dialog component. It kept trying to do clever things with CSS when all it needed to do was follow the fluent design path. We go there in the end but this was one task that would have taken me minutes to resolve manually, and it took Codex more than a dozen attempts.

A tidy package

The resulting solution package that Codex built was tiny, compared to my previous (manual) projects. In them if I get the solution package to build to be under 2Mb then I’m happy enough but K-Pulse is less than 300Kb – that’s just amazeballs!!!

The bottom line

Did I succeed in building a production ready solution using Codex without writing a single line of code myself – yes absolutely I did!

Go visit the web site at https://kaboodle.software/Solutions/K-Connect/K-Connect-Pulse download it and give it a try. I guess this is still a beta and any constructive feedback is most welcome. It’s not in the Microsoft Marketplace yet, but I will push it there in the next few weeks.

Did I enjoy the experience – yes, I think I did. It was frustrating at times, but it was also incredible to see just what AI can do.

Do I think me days as writing code are over – yes, I think they might be. I think I will build all my future projects this way.

Can anyone do this – mmm, tricky but I think not. I think anyone with an IT technical background and not necessarily a developer (lets call that person a Technical BA) could probably get a good concept demonstrator up and running but there is a significant gap between that and having a solution ready to be unleashed on real users. I personally think that because I knew all the right ways to nudge Codex makes all the difference – the only thing is that I am not sure how long things will remain that way!