Friday, May 30, 2025

Will AI make all code eventually look like demo code?

AI + learning code = ?

In the future, more code will be written by AI.

That AI will be trained by looking at existing code and documentation on the web.

For new libraries, APIs, functionality, etc. AI will first learn from the documentation, because there are no other examples to learn from.

Documentation and demo code contains unnecessary details and comments. It's also usually verbose and does not include many important considerations, like security, performance, logging, error handling, etc.

If that's all there is, how will the AI learn what better will look like?


It's already happening. 
When I have AI generate test cases, it frequently includes comments that only make sense in the context of teaching someone how to write test code. Why else would you include the single word "Assert" in a comment above a line that asserts whether a condition is met? Is such a comment necessary when the next line starts "Assert.IsTrue("? The AI does this because that's what it "saw" in the training data. And that training data included these comments because it was an instructional example, or was included in code that copied directly from examples like that.


Maybe it doesn't matter.

Maybe AI will learn to overcome this.

Maybe it's an indication that while AI may be able to write code that appears to work, it will still require people who have a different (and broader) understanding to ensure it works well, efficiently, and does everything that's needed. Not just what you might see in a demo.

Thursday, May 29, 2025

I went to Interesting 2025

hello

I went to Interesting 2025 (in London, the other week). Fourteen talks, from fifteen speakers, on very different topics.

But, I didn't find it interesting. I found it:

  • Inspiring
  • Curious
  • Terrifying
  • Intriguing
  • Surprising
  • Sad
  • Heart-warming
  • Hunger-inducing
  • Hopeful
  • Misleading
  • Unbelievable
  • Educational
  • Inspiring (again)
  • Triggering
  • Motivating
  • Wondering

which was really the point!


Thank you to: Alice, Rosa (& dad), Julia, Cate, Zoe, Lisa, Daniel, Rachel, Jackie, Terry, Lauren, Luyanda, Clare, Daria, Anthony, Helen, Rebekah, and especially Russel.


As one of the hosts said, "That was really interesting. Actually!" 


I went to Interesting 2025, I committed a rudeness, and I suffered as a result. (IYKYK😉)

Thank YOU (Russel)


Wednesday, May 28, 2025

Tuesday, May 27, 2025

I'm making Visual Studio less secure because I won't pay a 3rd party for security theatre

Which is less secure:

  • preventing the application of security patches?
  • not having signed assemblies?
It depends on context. So, what if I reframe the questions: 

How much would you pay to update an assembly that was previously signed?

If you don't pay, you can't update that assembly.

You can release another version (with a different name), but existing users won't get a notification of an available update.

no more extensions?


For "reasons", I previously signed the libraries I released through NuGet and the extensions I released through the Visual Studio Marketplace.

The cost to renew my code signing certificate this year was over $800. This is more than I want or have to spend on this. (Especially given the quality of the support they provide. or not.)


Microsoft offer an alternative at a reasonable price, but it's only available to companies registered in the USA or Canada. I'm not, so that's no help.


NuGet makes it possible to release unsigned updates to previously signed packages. So, that's good.

Sadly, Visual Studio does not. I even asked very nicely. However, I was told that for security reasons, they do not allow this.

I guess the consequences of extensions not getting updated to address security threats or security vulnerabilities in their dependencies aren't a problem.

If they didn't allow the uploading and distribution of unsigned extensions it wouldn't be such an issue. But, because I was previously trying to be good and sign things on the basis that it was better for security, I (and anyone wanting updates) suffer now.

Unless someone wants to sponsor me enough to cover the cost of a certificate, the 50 extensions I have in the marketplace will never be updated. If you're waiting on a fix (or a security update), I'm not sure what to tell you.


I'm still wondering what to do. Hopefully, I'll have an announcement in the coming weeks...




ENAMEL RFC Revision 1

I've just released the first update to the RFC for the ENAMEL language.

This is only the first of several expected revisions and adds a few new options and clarifications.

Changes in this revision:

  • Trailing semicolon is optional with inline C# (clarification)
  • Nested loops are supported (clarification)
  • Nested AUTOGRIDs are not supported (clarification)
  • Add the ExpandGridDefinitions setting
  • Add the SET keyword


As before, I appreciate any feedback on these changes or anything related.

Additionally, as I continue to explore these ideas and gain feedback from others, it's looking more and more likely that I will eventually release some tooling to support this language. I'd love your thoughts on this (including if you want to be an early tester) at https://forms.gle/DXVP8fjfyics74Sj6