Day 13: From Building to Managing - My First Real AI Sprint

After getting the initial versions of the tools into Dynamics, today became entirely focused on one thing: getting them to actually work.

Up until now, most of the effort had gone into building the system and generating the code. But bringing that code into Dynamics exposed a different layer of complexity. What worked in isolation was not behaving the same way inside the platform.

The main issue was that the web resources were not loading or executing as expected. At first glance, everything looked correct. The files were uploaded, the references seemed right, and there were no obvious syntax errors. But the functionality simply was not there.

This is where the nature of the problem shifted. It was no longer about writing code. It was about understanding how Dynamics actually serves and executes web resources.

One thing that stood out to me during this process is that even though I work in Dynamics regularly from a support perspective, I rarely have to deploy and wire up my own web resources from scratch. Most of my experience has been troubleshooting issues within existing implementations, not building and integrating new ones end-to-end.

This ended up being a valuable learning moment. It forced me to go deeper into how the platform actually behaves behind the scenes, rather than just how it presents itself from a support standpoint. It also highlighted the difference between diagnosing a problem and building something that needs to work reliably from the ground up.

Through testing and iteration, a few key issues started to surface. One of the first was how web resources are referenced. The distinction between display names and actual resource names became important. What looks correct in the UI is not always what the system expects when loading a script.

Another issue was script loading paths. Referencing the correct path for JavaScript files is critical, and even small inconsistencies can cause the entire resource to fail silently. This made debugging more difficult because there were no clear error messages pointing to a single root cause.

There was also the matter of publishing. Saving changes to a web resource is not enough. The resource must be published before Dynamics will serve the updated version. Without that step, it is easy to end up testing outdated code and chasing issues that have already been fixed.

On top of that, browser caching introduced another layer of confusion. Even after making changes and publishing them, the browser may still serve an older version of the script. This made it necessary to verify changes through direct resource URLs and developer tools rather than relying on the UI alone.

Individually, none of these issues are particularly complex. But together, they create a system where small mistakes can compound and make debugging feel unclear and inconsistent.

The breakthrough came when everything was aligned correctly. The resource name matched the reference, the script path was correct, the resource was published, and the browser was loading the latest version. Once those pieces were in place, the web resource loaded and executed as expected.

This was one of the more satisfying moments in the project so far. Not because of the complexity of the solution, but because it required a deeper understanding of both the platform and the process.

Today reinforced an important lesson. Building functionality is only part of the work. Understanding the environment where that functionality lives is just as important. It also reinforced something more personal: moving from support into product means not just understanding systems when they break, but understanding how to build them so they work in the first place.

With this issue resolved, the path forward is much clearer. The focus can now shift back to building out the actual tools, knowing that the foundation for deploying and testing them inside Dynamics is working properly.