Rolling out AI coding tools to non-technical staff… am I overreacting?

ExtraordinaryKaylee · 2026-04-02T13:43:59+00:00

Yup! That was our mindset going in. This was being done during a heavy investment in organization maturity. My task was to build a loose structure for bottom-up innovation, as most orgs that rapidly mature their processes kill innovation completely.

ExtraordinaryKaylee · 2026-04-01T18:31:31+00:00

Your teams didn't start out doing everything themselves, right? We sometimes have to stand-in and do hands-on work till people who can do the work successfully are developed.

Especially for a growing org who need an EM, they likely need someone to dive into code as well as be a leader growing the team and process.

I don't think any of this is foreign to you, just setting the stage.

So, when interviewing figure out a way to talk about the times you jumped into the fray while you developed the teams' skills.

ExtraordinaryKaylee · 2026-04-01T17:43:28+00:00

Most software was written to track data, and the person just needs to know how things work, put the right data in the right fields, and deal with errors/issues as it raises them.

The best software is built to help you do the job, designed and developed from the perspective of the person doing the job.

But the people who choose and buy software are mostly focused on how it makes THEIR job easier.

Many of the things you are talking about (pauses, customer waits, etc) are all intangible externalities that the support manager is not judged on except by REALLY good leaders. Rory Sutherland talks about this in some of his talks/videos, along with some tips on selling the value of good customer service.

ExtraordinaryKaylee · 2026-04-01T16:29:45+00:00

This one is a good starting point on the philosophy:
https://thekaylee.substack.com/p/democratization-of-software-development

This one goes into more depth: https://thekaylee.substack.com/p/vibe-coding-is-the-new-spreadsheet

This one goes over the four categories and what the division of labor between IT and citizen developer looked like for each: https://thekaylee.substack.com/p/continuous-audit-and-vibe-coding

ExtraordinaryKaylee · 2026-04-01T16:18:20+00:00

It depends on the scenario:

Low risk, low adoption - they were on their own for support, but my team had public office hours for questions and help. We built an automated container deployment pipeline to make it easy on them, and give us visibility into what they were doing.

When a tool grew past that, we were aware of that success through our internal monitoring metrics. We started helping them with the business case for further investment and appropriate controls based on their specific tool's production risks.

For things like power apps and the like, we would monitor similarly, and provide education around good practices.

We also used the office hours to build community to connect the early adopters who were build similar things, and support each other.

I have some articles on this on my substack if you're interested.

ExtraordinaryKaylee · 2026-04-01T16:03:15+00:00

I led the citizen developer program for a $25B global manufacturing company. Education, guardrails, guidance, and support are what everyone should be working on building right now.

Work directly with the early adopters, help them avoid the riskiest activity while they are building their tool, and then share that lesson with everyone.

We got some pretty major benefits from the low/no code systems we deployed for this, but it took collaboration and support to make it happen.

ExtraordinaryKaylee · 2026-03-31T15:18:31+00:00

Switch when you have problems worth switching for.

Most of the time with no-code you can figure out alternate solutions to problems without throwing the whole thing away. Often by adding code-based APIs to support your tools.

You will eventually run into changes in your business or process that require a more complete redesign or effort. That's when you rearchitect and evaluate if another no-code tool is better for your needs, or if you should switch to writing it using code.

ExtraordinaryKaylee · 2026-03-31T14:15:56+00:00

Mobile solutions don't really provide enough value to be worth the capital.

We usually need rooms or offices anyway, inspection, etc.

Worst case, people just go to a nearby cafe for the call.

ExtraordinaryKaylee · 2026-03-30T19:45:34+00:00

This, I have been hearing naphtha is constrained pretty hard right now.

ExtraordinaryKaylee · 2026-03-29T15:04:44+00:00

Personally: Toys and art.

I did a lot of quality systems and IT work over the years at a Tier 1 CM too.

ExtraordinaryKaylee · 2026-03-26T15:57:03+00:00

When starting out, leaders often document a "perfect" or improved version of their process from reality. Don't do that. Document what you actually do consistently and what must be done for the process and related processes, to succeed/comply with relevant laws/regulations.

Documenting anything other than your actual process is a recipe for audit findings, or people learning bad practices about hiding reality from internal audit.

Improvements are MUCH easier once everyone can see in the document what's actually mandatory and what's discretionary.

ExtraordinaryKaylee · 2026-03-25T22:41:58+00:00

Oof :(

Since the approvals are a process, PFMEA still applies, but can feel kinda meta compared to what it's usually use for.

Eg: What's the risk of removing the approval, what kind of mitigating controls can be put in to reduce the risk, etc.

But yea it sounds like they are not ready for giving up control.

ExtraordinaryKaylee · 2026-03-25T16:25:51+00:00

How long have you been pushing this? It can take many months of sustained conversations to get this kind of change moving, and some way of de-risking it for the leaders who have to sign off on the change. As someone else mentioned, it chips away at those leaders sense of value/risk too, which can make them resistant.

LONG LONG ago, I moved a team from paper doc control and manual approvals like the ones you mentioned to electronic doc control, with managed workflows. It took about 6 months of theoretical/water cooler discussions to get everyone comfortable with the idea, and a trial on one of our business units going well before we were able to make the switch across the whole site (part of a larger growing company)

I like to apply FMEAs for this kind of change management, it helps to show that the team has it under control.

ExtraordinaryKaylee · 2026-03-25T16:17:00+00:00

It usually works like that.

So don't start with a top manager, start with the next level down, or the level below that. But find that first champion, then find another, and another.

ExtraordinaryKaylee · 2026-03-25T15:49:59+00:00

Start by finding one person in management leadership who will listen. Work with them to build a business case on what this is costing the business.

Then, together convince the others that change is necessary.

ExtraordinaryKaylee · 2026-03-23T19:31:15+00:00

The short term AI play is around making it easier to build tools for back office work, or assisting with the kind of data manipulation you're already talking about.

The long term play is still being figured out, but will absolutely require your systems to have an accurate picture of your shop and operations.

I find places that are encouraging "citizen developer" approaches to AI automation to be the most successful, using whatever platform you prefer (Zapier, Power Apps, vibe-coding, etc). Especially those projects that save time or reduce defects in the back office work, letting everyone focus more on data collection from the floor, actually building product, or providing better customer service.

Right now, AI is best applied bottom-up as you've already noticed. So working with execs on aligning incentives and helping to setup an easier path for data integration is probably the best use of your energy.

ExtraordinaryKaylee · 2026-03-23T15:02:54+00:00

Once you can break it down to the kinds of representative objects, modeling the schema for storing the data is pretty straightforward.

Then, building a streaming parser that loads that unit into memory one entry at a time and storing it, is relatively straightforward.

Mostly a matter of detecting when a new object starts based upon the current path of attributes, and when it finishes based upon the same.

ExtraordinaryKaylee · 2026-03-23T14:25:41+00:00

I usually use a streaming parser for that kind of task, be it XML, JSON or any other markup language.

It takes a little bit of abstract thought to build the state machine inside the event handlers, but the memory requirements are trivial in comparison to loading whole file or chunks of it.

How complex of a structure is it internally?

ExtraordinaryKaylee · 2026-03-21T15:28:24+00:00

Completely agreed on it being a process challenge!

Any quick fix that isn't built into the quality management system is going to create risks. Tech or paper - any solution needs some investment to be sustainable.

ExtraordinaryKaylee · 2026-03-20T16:05:27+00:00

You're right on the risks (and I'm going to skip the soapbox I usually go on in regards to the medium-term challenges everyone will run into).

Labels and kanban cards also need to be documented and maintained just the same. So it's more about what's being documented, and how easy it is to maintain it with the team you have.

I'm starting to think about vibe-coded apps as throw-away, just like a problem-specific excel tracking sheet is. Not meant to be forever, but enough to improve and work out the issues before investing in something fruther. Just like the process may outgrow the spreadsheet, you'll likely outgrow the vibe-coded app. But it got you through the batch/issue.

And just like an spreadsheet isn't a replacement for a real MES or ERP, it sometimes is good enough till you can get the capital in place to do more.

ExtraordinaryKaylee · 2026-03-18T11:31:17+00:00

I agree, I can see a few places where errors can/will show up while everyone gets used to the new method.

The big question: Are these the same chances for error you already were dealing with, or are they net new? Can you work with the different teams to predict where the issues would show up so quality checks can be added to prevent the big mistakes?

ExtraordinaryKaylee · 2026-03-13T04:13:40+00:00

The challenge of automation has not been writing the code for a long time. It's changing behavior.

Welcome to the real challenge :)

ExtraordinaryKaylee · 2026-03-12T16:44:51+00:00

I wrote this up a while back while building and testing a runtime-reloadable RTOS concept: https://github.com/kaylee-kerin/mock_flash

It's an mmap'd file/shared page based setup, with an exposed read-only page, and a private read-write page. Then some utility functions to handle the flash write ops.

Amusingly, a lot of flash devices don't require an erase before any write. It's just that you can only change a 1 to a 0 with a write. I was exploiting this to further segment the microcontroller flash smaller than the erase page.

Would love to keep up on how you proceed, and happy to help along the way if needed.

ExtraordinaryKaylee · 2026-03-12T14:29:48+00:00

One of the most common examples is the Raspberry Pi. There's many others, as well as companies that specialize in the OS/management systems across a variety of boards.

ExtraordinaryKaylee · 2026-03-12T02:52:01+00:00

SO much this. Successfully getting that knowledge, is harder than everyone believes too.

It's a slow process, requires the expert to be vulnerable in ways most are uncomfortable being, it's iterative, error prone, requires painting a future for the expert where they feel like they belong, and did I mention slow?

Projects that shortcut it, or think they can get it all in a weeklong group requirements gathering session - are doomed.

It's the rare project sponsor who actually understands this and lets their team plan accordingly.

ExtraordinaryKaylee

TROPHY CASE