08:00: I open my editor. My files are riddled with red-tape big-tech NASA-style governance gates. 'Get signoff from library maintainers and project governance committee before merge'. If those groups existed, I would be part of both.
Despite its enthusiasm for governance and processes, when I tell the clarification agent there's a disconnect between the specification and the build plan it goes on to invent a 'memory' markdown file outside of its workflow instructions.
11:00: Standup and refinement done, coffee hot. New message from Jan - 'you need to fetch the latest agent instructions - and don't forget to refresh your wiki cache'
Jan went on a two-week vacation to somewhere in Africa over Easter and upon his return he churned out three different organisational matrices and a draft of a methodology for AI governance. Judging by his level of obsession I'd say he's one bad week away from writing a book and retiring to the lecture circuit.
Like everything he does, Jan's idea for a governance framework is calculated and simple. There's one chief deliverable, a few permitted artefacts, a rule that context should come from our wiki, a highly contentious notion that developers shouldn't concern themselves too much with the code that is generated - only its behavior, which should be tested rigorously. At night I can hear the walls echoing his favourite principle - 'convention over configuration over code'.
Our other developer-colleague turned agent-hostage Sebastian looks at us as if we've caught some virus. No one is talking about code anymore. It's just tools, agents and central markdown repositories. I'm writing and polishing new wiki articles, creating agents, refining specification artefacts and creating PRs for features written entirely by agents.
14:00: 'Jan: Perhaps we need an agent for pull requests? I'm also testing a new skill to improve wiki lookup'
Our team is small, but we have lots of experience in Jan and Sebastian - two senior devs with just as much knowledge in the ways of code as politics. Having worked with these two Germans for more than a year, I understood that a free-for-all, vibe-code token frenzy would never fly. Governance is, for them, a survival tool, a chance to shape their environment into a space where they can experiment, develop and improve without stepping on anyone's toes. Getting sign-off on ways of working means keeping their backs free. It gives them control.
So it's not so strange that we've ended up in a situation where all agentic development focuses on one chief deliverable - a technical specification that describes, as far as possible, the desired behavior of a system. If the code doesn't deliver the correct results - the correct behavior - the specification is bad. A single commit with +3,000 lines of code? Doesn't matter - only the behaviour matters, and the spec should declare how to test behavior. It's radical and, if I'm honest, quite brilliant. Yet, I'm still on the fence - surely it can't be good for maintenance to have all this verbose code flying around? Perhaps I'm just upset I have years of joyless markdown editing ahead of me.
Sometimes I cheat, I write some code by hand, and then Jan will ask me - 'where is the spec?'.
'Come on, it would have been a nightmare for this small change'.
'But how are the agents going to get better?'.
As a team, the challenge of improving an agent has little to do with the quality of code produced in a given session but more to do with consistency across sessions. We want our agents to feel as though they really understand our environment and the way we work.
16:00: 'Sebastian: Hey guys, the implementation agent couldn't figure out which version of our library to use - I've updated the wiki.'
Our most significant improvements have come from making implicit knowledge explicit. What we never anticipated is just how explicit we would have to be. Of course, our wiki articles have to contain exhaustive information about our environments, standards and processes, but we also discovered that there needs to be some mechanism to relate one piece of knowledge to another.
To build this world for our agents, we ditched pair-coding sessions for wiki meetings. After two-three weeks of reworking wiki articles and instructing, or rather forcing, agents to look for tags in a locally stored index of the wiki, we had something. The agents are now internalizing our knowledge, and the map is starting to reflect the terrain. Sebastian built his own readme agent which is now the foundation for all our readmes. I created a release notes agent using a wiki article we had all refined together.
Force-feeding agents this way may not sound too impressive if you're a FAANG-level engineer, but I'd wager most of us sit on heaps of unstructured and informal knowledge that our new hires consistently struggle to internalize. If they can't use our docs to explain the desired behavior of a system, an agent certainly can't.
17:00: Save progress on an ongoing specification. 15 open questions. Most answers should have been found by the agent during research. I guess I'll update the wiki tomorrow.