Hour a Day: AI - Day 7 - The Power of Conventions
As a recap since there was a break yesterday: we’re focusing on starting to get tests written for our service.
Making Stubs Prompt:
I’d like you to create ut test stubs for the classes that I have (skipping the main entrypoint). Don’t fill out the implementations but ffeel free to create setup methods that setup up the needed dependencies. In general these are unit level tests so anything injected should be mocked.
Hour a Day: AI - Day 6 - Something a little different
Today is going to be a little different as my “hour” of ai was over a brownbag during lunch. Multiple people from work shared success and failure stories from their own personal ai adventures.
Mostly the things they said were things that were on my radar but it was good to hear some new ideas too. I’m planning on trying out some of those learnings into this series as well.
Hour a Day: AI - Day 5 - Total Failure
Today is going to be a little short on the prose department, I’m already over my hour starting to write this 馃槺
Create a test project Prompt:
Can you create a test project for llm-history-to-post.csproj
Response:
llm-history-to-post/llm-history-to-post.csproj
Add file to the chat? (Y)es/(N)o/(D)on’t ask again [Yes]: y
Hour a Day: AI - Day 4 - Something Functional
Yesterday we took a stab at having aider implement our history to blog post service based on the requirements doc that we had cleaned up on day 2. I ran out of time to talk about it, but it had a pretty big issue.
I was using aider’s architect mode to create the application. Which acts like a psuedo reasoning system where it uses the prompt entered into the cli to create another prompt to then feed into code generation. The problem with this is in the history file the user entered prompts and the reasoning prompts are indistinguishable. See the following example.
Hour a Day: AI - Day 3 - Getting something running
Introduction Yesterday we went through and iterated over requirements for a tool that will help write these blog posts. Let’s see how it plays out feeding these requirements into the llm and asking it to implement it!
First Try Prompt:
Hour a Day: AI - Day 2 - Starting off with a plan
In yesterday’s post, I got all the blog’s dependencies updated and the blog building with the help of my new best friend Claude + Aider.
It did take a substantial amount of time to format the blog though with all the prompts involved and manually copying and pasting from the history file.
So I think the first thing to do as part of this adventure is make writing about the adventure a lot easier! Let’s automate it!
Hour a Day: AI - Day 1 - The Blog
The last year has been filled with moments of me oscillating between being dismissive and absolutely terrified by how AI tools will affect the software development industry. Over the last couple of months I’ve gotten my feet wet, but I figured why not ramp it up a notch? I’m going to try to spend an hour a day exploring these tools for the next year and record my successes and failures. At worst at the end of the year I’ve spent a lot more time on personal projects. At best, I’ll feel a lot more comfortable with the future of software development! So let’s get into it! at the moment my tools of choice are
RPG Development Log #4
I’ve been meaning to write this blog post for a while! Looking back at the commit history, this was done nearly a month ago! As mentioned last time, the plan was to work on adding choice selection to the user. And that’s exactly what happened!
Choice Menu At first glance the choice system seemed like something that should be an extension of the messaging system. “All” that would require would be adding a few parameters to the current interfaces, adding some new display code, and adding new logic to handle user input. Okay so that might actually be a lot. I was part way through with this change and ended up starting from scratch for a couple of reasons.
RPG Development Log #3
I thought this blog post would be about the creating the plot placing menu but turns out there was a decent amount of work to on the messaging system before I could even get started!
Before Before going down the route of refactoring, the test NPC had display dialogue code that looked something like this:
public override Task Interact(ICharacter initiator) { return MessageDisplayManager.Display(new[] { "Hi, I can talk.", "Here's some more text." }); } This was fairly basic. Pass in an array of messages to display and the display manager would handle showing text when the user pressed the action key. It returned a task so that the caller could know when the message was finished displaying. For our purposes, this allowed the npc to start facing the direction they were facing before the conversation started.
RPG Development Log #2
Time for another dev log! This week there was a mix of refactoring / new functionality.
Refactoring The logic that was handling player input specifically checked if a message box was open before continuing. This works out well for a small number of input handlers, but doesn’t scale so well when there are a large number of different flows that need to respond to player input (e.g. a menu, a choice selection screen for dialogue).