A note about this build log entry: I published this after the week it covers. DevNitro reconstructed a draft from work-related entries in my journal, Git commit history, and time tracking. I reviewed, edited, and approved the final post. The story reflects what I knew and built at the time.
From the Backlog to the Build Log
Week of May 1 - May 7, 2026
What I Worked On
This was a shorter week, part of it away from the desk attending my oldest daughter's college graduation. So I picked one thing that had been bugging me and finished it: nobody should have to talk to the database.
Up to now, an issue or a memory was identified by an opaque database ID. You cannot say "hey, look at issue 4f3a9c2e" to a teammate and expect anything good to happen. So I gave everything human references. Issues now get a per-project sequential number with a prefix, like DN42. Memories get refs like MEM123, numbered per company. And URLs moved to company-scoped slugs instead of raw IDs, so a link actually reads like something and routes to the right place.
The part I am proud of is that existing setups upgrade themselves. I wrote automatic legacy config migration that rewrites old ID-based configuration into the new slug format on the fly, with tests, so nobody has to hand-edit a config file to come along. Changing how you identify things is one of the scariest refactors there is, because every old link and reference has to keep working. Doing it without a manual migration step is the difference between a feature people adopt and one they resent.
I also extended the skills system. There is now a third kind of skill, a Tool Skill: an LLM-callable tool you define with a small tool.json, so you can hand the agent a new capability without writing a provider. I added a create-skill built-in to bootstrap that, and skill enforcement levels, Convention and Policy, so an organization can make a skill a gentle suggestion or a hard requirement.
What the AI Did Well
The agent handled the wide, delicate identity migration well: per-project numbering, slug routing, external IDs, and the legacy auto-migration path, all with tests. It also added Git worktree support to the Git Explorer, so when parallel agents each work in their own worktree, you can actually see and switch between them from the UI. That is visible parallel work made literal: a governed place for each concurrent agent, not a pile of branches you cannot see.
What Needed Correction
Identity migrations punish sloppiness. One fix I want to call out is small but telling: preserving file encoding during read-modify-write operations. When the agent edits a file, it must write it back in the same encoding it found, or you get invisible corruption that shows up as a broken diff days later. I also had to tune the small stuff, like allowing a one-character issue prefix, because real teams want short refs.
The reasoning-effort work also needed care: I made effort selectable and persistent per model, so a heavier model can run at a lower effort for cheap tasks. Getting that to persist correctly across a conversation took a couple of passes.
What Shipped
DevNitro gives issues and memories human references, DN42 and MEM123, with company-scoped slug routing and automatic legacy config migration. Skills gained a Tool Skill type via tool.json, a create-skill built-in, and Convention and Policy enforcement levels. The Git Explorer supports worktrees for visible parallel work, and reasoning effort is selectable and persistent per model.
The Numbers
| Category | Hours |
|---|---|
| Product / Features | 18h 47m |
| Deploy / Infra | 3h 25m |
| Content | 2h 51m |
| Testing | 2h 13m |
| Docs / Skills | 2h 7m |
| Total | 29h 24m |
A lighter twenty-nine-hour week, most of it on the one thing that makes a tool feel like a product: references a human can read, say out loud, and paste into a message.
Software a team can trust, support, and scale has to be software a team can talk about. "Fix DN42" is a line in an email or slack message that immediately conveys important project information to everyone. A database ID is not. Small change, big difference, and exactly the kind of detail that separates a demo from something people actually run together.
Curious how this site was built?
Watch the 5-minute walkthrough at devnitro.com →
0 Comments
No comments yet. Be the first to share your thoughts!
Leave a comment