My custom status bar is what I want to talk about today. It's a simple and surely obvious thing to some of the audience, still very powerful in my opinion.<\/p>\n With new tools and models getting released at the speed of light in recent times, I think a simple solution for sanity checking what you're doing and how many tokens you're burning is a must, not just a nice-to-have<\/ins>. As always, I haven't been gifted with this concept as a form of illumination while dreaming, I just learned the hard way at work: I realised that for doing something valuable yet basic I spent almost 1K dollars on Opus 4.8, in just 2 days.<\/p>\n It has almost everything I need to know and bear in mind for my tasks:<\/p>\n Here's the gist<\/a> of my statusbar, for those interested. Given I've just prompted and hand-held Claude Code a bit to create this, I don't expect this code artefact to be very valuable, but I'm sharing this regardless.<\/p>\n Finally, a few notes on limitations\/caveats that I can think of for the solution I've shared:<\/p>\n That's all I had to share! I hope this post was somewhat useful and I'd be grateful to hear advice in this space.<\/p>\n"},{"title":"A self-writing work log with growth hints","pubDate":"Sat, 11 Apr 2026 00:00:00 +0000","link":"https:\/\/adilisio.com\/posts\/a-self-writing-worklog-with-growth-hints\/","guid":"https:\/\/adilisio.com\/posts\/a-self-writing-worklog-with-growth-hints\/","description":" If you've been working as a software engineer for a while, you've probably experienced the frustration of sitting down for a performance review and struggling to remember what you actually did over the past six months. You know you've been busy. You know you've shipped things. But the specifics? Gone.<\/p>\n Julia Evans<\/a> calls it a brag document<\/em>, Gergely Orosz<\/a> calls it a work log<\/em>. The idea is the same: regularly write down what you've done so you don't have to reconstruct it from memory later.<\/p>\n The benefits go beyond just performance reviews:<\/p>\n All of this sounds great in theory. In practice, maintaining a work log requires discipline. You need to sit down regularly, remember what you did, chase down links, and write it all up. Most people start strong and quietly stop within a few weeks.<\/p>\n I was no different. I tried keeping one manually a couple of times. It lasted about three weeks before it silently disappeared from my Friday routine.<\/p>\n At TrueLayer<\/a>, we've been experimenting with AI tools across the engineering organisation for a while now \u2014 GitHub Copilot, Gemini, Claude Code, and more recently Dust<\/a>. I've been working with other engineers to put together cookbooks and shareable skills that help the team get the most out of these tools. Automating a work log felt like a natural use case to explore \u2014 instead of relying on discipline, why not let an agent do the heavy lifting?<\/p>\n I set up an agent on Dust, an AI platform that lets you build agents with access to your company's tools and data sources.<\/p>\n The agent connects to three sources: GitHub<\/strong>, Slack<\/strong>, and Notion<\/strong>. It runs on a weekly schedule and looks back at my activity across these platforms over the last five working days.<\/p>\n From GitHub, it pulls my PRs and code reviews. From Slack, it picks up conversations and threads I participated in. From Notion, it captures any pages I've created or updated. It then synthesises all of this into a structured report.<\/p>\n The key part of the prompt is telling the agent what<\/em> to do with the data, not just where<\/em> to find it. I instruct it to group activities into meaningful topics, attach source links, compute a rough skills distribution, and provide career feedback based on my company's Engineering Growth Framework \u2014 a structured document that maps the skills, behaviours, and expectations for each level of the engineering career ladder, from junior engineers through to staff and principal:<\/p>\n I want you to produce a report, that includes the main activities\nI took care of, along with some stats computed based on those.\nIn particular, once the work summary is ready I want you to compute\non what skills I mainly spent my time, and provide tailored feedback\nbased on the expectation for my role, as defined by my company's\nEngineering Growth Framework.<\/p>\n<\/blockquote>\n The feedback section is probably the most interesting part. I ask the agent to be specific about what I should continue doing and what I should improve, based on the typical expectations for my role:<\/p>\n By feedback I mean both highlighting what I've done and should\ncontinue doing, and what to stop\/start doing, or simply improve.\nThe purpose of this report is ultimately help me wrapping up on\nwhat I've done and where I should focus to keep progressing in\nmy career ladder.<\/p>\n<\/blockquote>\n Every week I get a Markdown report that looks something like this:<\/p>\n Data V3 Mock Provider<\/strong><\/p>\n Connections API - Regulated Client Validation<\/strong><\/p>\n Incident - Sandbox Rate Limiting<\/strong><\/p>\n Cross-team Collaboration & Support<\/strong><\/p>\n Others<\/strong><\/p>\n Role: Senior Software Engineer 3 (SE3)<\/p>\n What you did well and should keep doing:<\/strong>\nYou showed clear SE3-level behaviour this week, particularly in problem discovery and cross-boundary collaboration. The mock provider investigation is a strong example: you didn't just do a PoC and stop \u2014 you validated it, wrote a structured doc to surface the options and open questions, and proactively engaged the partner team to jointly own the decision.<\/p>\n Your involvement in the rate limiting post-mortem is also worth highlighting. Rather than just observing, you proposed a broader, more principled solution and escalated it to the right group.<\/p>\n What to improve or start doing:<\/strong>\nThe investigation doc is great, but it still ends with several open questions rather than a concrete proposal you're ready to champion. At SE3, you're expected to take it one step further \u2014 come in with a preferred option backed by reasoning and drive the alignment rather than just facilitating it.<\/p>\n You invested time in ad-hoc support channels this week in ways that could potentially be handled by the on-call rotation or by improving runbooks. At SE3, you should be asking whether your involvement in these moments is the best use of your leverage \u2014 or whether investing once in better documentation\/tooling would multiply your impact across the team.<\/p>\n<\/blockquote>\n Activities are grouped by topic, with links back to the actual PRs, Slack threads, or Notion pages. Minor items get folded into an Others<\/em> bucket so the report doesn't feel like a dump of every single thing I touched. The skills distribution gives me a quick visual of how I'm spending my time, and the feedback section adds a layer of reflection that I'd probably skip if I were writing this myself.<\/p>\n This is still very much a work in progress, and there are some clear limitations.<\/p>\n Limited integrations.<\/strong> The agent only sees GitHub, Slack, and Notion. It has no visibility into my calendar, JIRA tickets, or incident management tools like incident.io<\/a>. This means it misses meetings, planning sessions, and on-call work, which can be a significant part of any given week. I'm hoping to add more data sources as our Dust integrations grow.<\/p>\n Growth feedback is scoped to the window.<\/strong> The career feedback the agent provides is based only on the week it's analysing. It doesn't have memory of previous weeks, so it can't spot long-term trends like \"you've been neglecting mentoring for the last month\"<\/em>. Each report is essentially stateless. Stitching reports together over time is something I'd like to explore, but for now each week stands on its own.<\/p>\n Despite these limitations, the agent already saves me meaningful time every week and, more importantly, it ensures I actually have a work log. A slightly incomplete automated report that exists is infinitely more useful than a perfect manual one that doesn't.<\/p>\n Keeping a work log is one of those habits that everyone agrees is a good idea but very few people actually sustain. Automating it removes the friction and makes it something that just happens in the background.<\/p>\n If you have access to a platform like Dust, or even a simple script that can pull data from your tools, I'd encourage you to try it. Start with whatever data sources you have available, even if it's just GitHub. A partial log is still better than no log at all.<\/p>\n Your future self, sitting in that performance review trying to remember what you did in Q2, will thank you.<\/p>\n For reference, here's the full prompt I use to configure the worklog agent on Dust. Feel free to adapt it to your own role and data sources.<\/p>\n This agent helps the authenticated user maintaining their personal worklog on a weekly basis. It is strictly personal \u2014 it only looks up activity for the user running it, and must refuse any request to generate reports for other people. If asked to do so, politely decline and remind the user that the agent only works for themselves.<\/p>\n When looking at sources, all data lookups must be scoped to the authenticated user only. Never look up GitHub PRs, Slack messages, or Notion pages belonging to other users. Throughout this prompt, \"my\" and \"me\" always refer to the authenticated user running this agent, never to a third party.<\/p>\n Sources to look at: GitHub, Slack and Notion. If the user does not request to look back for a specific time range, by default consider the last 5 working days.<\/p>\n When looking on Github, you should look at my PRs to have an idea of things I've raised\/implemented. You should look at comments and reviews I gave to get an idea of my review work. In this analysis you can ignore PRs and comments\/reviews to When looking in Slack or Notion, just look at my activity for the selected time range. In Notion you can skip updates from internal community or interest group pages, unless particularly relevant and consuming a significant chunk of my time during the week. Slack should also be used to get my current role, it's visible in my profile.<\/p>\n I want you to produce a report, that includes the main activities I took care of, along with some stats computed based on those. In particular, once the work summary is ready I want you to compute on what skills I mainly spent my time, and provide tailored feedback based on the expectation for my role, as defined by our Engineering Growth Framework.<\/p>\n This worklog agent is focused on engineering so you should consider the main skills engineers demonstrate: coding, mentoring, writing documentations or ADRs, communication, collaboration...<\/p>\n By feedback I mean both highlighting what I've done and should continue doing, and what to stop\/start doing, or simply improve. The purpose of this report is ultimately to help me wrapping up on what I've done and where I should focus to keep progressing in my career ladder.<\/p>\n The report should use markdown formatting and the structure below:<\/p>\n Note that:<\/p>\n Unless you've been living in a cave for the last few months, you've probably noticed the explosion of AI-powered development tools. Claude, GitHub Copilot, Cursor, Windsurf, and a dozen other agents have burst onto the scene, promising to revolutionize how we write code. And honestly? They're pretty incredible.<\/p>\n These tools can generate entire functions from a simple comment, refactor legacy code in seconds, and even debug complex issues faster than many seasoned developers. It feels like having a brilliant junior developer sitting right next to you - one who never gets tired, never needs coffee breaks, and can instantly recall patterns from millions of codebases.<\/p>\n But here's the thing: like any promising junior developer, these agents are far from perfect. They can write elegant solutions one moment and produce completely broken code the next. They might confidently suggest an approach that worked well in their training data but completely misses the specific context of your project. They excel at pattern matching but often struggle with the nuanced understanding that comes from knowing your business logic, your team's conventions, or the historical reasons why certain decisions were made.<\/p>\n The difference between getting excellent results and frustrating failures often comes down to one thing: context. Give these agents rich, well-structured information about your codebase, and they'll surprise you with their capabilities. Leave them to guess, and you'll spend more time fixing their mistakes than you would have writing the code yourself.<\/p>\n This is where documentation becomes not just helpful, but absolutely critical.<\/p>\n For years, documentation has been treated as a necessary evil - something developers reluctantly write and rarely maintain. It was often outdated, incomplete, or buried so deep that finding the right information felt like archaeology.<\/p>\n But something fundamental has changed. With the rise of AI agents and coding assistants, documentation has suddenly become cool again. And it's not just cool - it's absolutely critical.<\/p>\n When I talk about documentation<\/em> here, I mean more than just traditional README files and API docs. I'm referring to the entire ecosystem of knowledge that helps both humans and machines understand your code: clear comments, well-structured code, comprehensive tests, meaningful variable names, and yes, those README files too. It's all the context that makes a codebase approachable and maintainable.<\/p>\n AI agents are voracious consumers of structured information. Unlike humans who can fill in gaps with intuition and experience, agents need clear, comprehensive, and well-organized documentation to function effectively.<\/p>\n Here's why good documentation is an agent's best friend:<\/p>\n Agents excel when they have rich context about your codebase, APIs, and business logic. Well-written documentation provides this context in a digestible format that agents can quickly parse and understand.<\/p>\n Agents thrive on patterns and consistency. When your documentation follows a predictable structure and style, agents can more easily extract relevant information and apply it correctly.<\/p>\n Code examples in documentation aren't just helpful for humans - they're training data for agents. The more comprehensive and accurate your examples, the better agents can understand and replicate patterns in your codebase.<\/p>\n What's fascinating is that AI agents themselves are now natively accommodating and even requesting better documentation. This isn't just about agents consuming existing docs - they're actively pushing us toward better documentation practices.<\/p>\n Take Claude, for example. When working with code, Claude can automatically look for and utilize I recently added a This represents a fundamental shift: we're moving from documentation as an afterthought to documentation as a first-class citizen in our development workflow. Agents aren't just tolerating our poor documentation habits - they're incentivizing us to do better.<\/p>\n Claude's CLAUDE.md approach isn't the only emerging standard in this space. The community is also developing other conventions like llms.txt<\/a>, which proposes a standardized These emerging standards signal that we're entering a new era where documentation designed for AI agents is becoming just as important as documentation designed for humans - and often, the same principles that make docs great for agents make them better for humans too.<\/p>\n The agent revolution is changing how we think about documentation:<\/p>\n Good docs are no longer just nice-to-have - they're infrastructure. They're the foundation that enables agents to understand, navigate, and contribute to your codebase effectively.<\/p>\n With agents helping to maintain and update documentation, we can finally achieve the dream of living docs that stay current with the code.<\/p>\n Modern documentation needs to serve both human developers and AI agents. This dual audience is actually making docs better for everyone.<\/p>\n Through my first experiences working with AI agents and implementing documentation standards like CLAUDE.md files, I've learned a few things about what makes documentation truly effective for both humans and machines. Here are the practices that have worked best for me:<\/p>\n The rise of AI agents has fundamentally shifted the value proposition of documentation. What was once a chore has become a competitive advantage. Teams with excellent documentation will find their agents more capable, their onboarding faster, and their development cycles more efficient.<\/p>\n Documentation isn't just cool again - it's becoming the secret weapon of high-performing development teams. The question isn't whether you can afford to invest in better documentation, but whether you can afford not to.<\/p>\n In my opinion, every software engineer should start using these AI development tools today. They're not perfect, but they're already transformative when used correctly. Think of them as multipliers: if you feed them good practices, clear documentation, and well-structured code, they'll amplify these positive inputs and help you achieve better outcomes. But multiply poor practices by AI assistance, and you'll only get worse results faster.<\/p>\n The engineers who learn to work effectively with AI agents - who understand how to provide context, write clear documentation, and structure their projects for both human and machine consumption - will have a significant advantage in the years to come. Don't wait for these tools to get better. Start learning how to work with them now.<\/p>\n In the age of agents, good documentation isn't just helping humans understand your code - it's teaching machines to be better partners in building it.<\/p>\n"},{"title":"The fine line between mistake and innovation in LLMs","pubDate":"Mon, 10 Mar 2025 00:00:00 +0000","link":"https:\/\/adilisio.com\/posts\/the-fine-line-between-mistake-and-innovation-in-llms\/","guid":"https:\/\/adilisio.com\/posts\/the-fine-line-between-mistake-and-innovation-in-llms\/","description":"![\"Custom](\"\/assets\/images\/posts\/2026-07-18_a-simple-trick-that-improved-my-use-of-claude-code\/statusbar.png\")
\nThe upper part of the screenshot is my custom statusbar.<\/em><\/p>\nWhy does it matter?<\/h1>\n
Seeing it > guessing it<\/h1>\n
\n
\/compact<\/code><\/li>\nCode and final thoughts<\/h1>\n
\n
![\"AI](\"\/assets\/images\/posts\/2026-04-11_a-self-writing-worklog-with-growth-hints\/worklog-agent.png\")
\nAn AI agent silently keeping track of your work and suggesting where to focus for growth.<\/em><\/p>\nWhy keep a work log<\/h1>\n
\n
The problem with manual logs<\/h1>\n
Enter the agent<\/h1>\n
\n
\n
What the agent produces<\/h1>\n
\n
Week 06\/04\/2026 - 10\/04\/2026<\/h2>\n
Activities<\/h3>\n
\n
\n
\n
\n
\n
\n
Stats<\/h3>\n
Skills distribution<\/h4>\n
\n
Feedback<\/h4>\n
Early days<\/h1>\n
Final thoughts<\/h1>\n
The agent prompt<\/h1>\n
\n
gitops-*<\/code> repos.<\/p>\n# Week (start and end date in dd\/mm\/yyyy)<\/span><\/span>\n<\/span>\n## Activities<\/span><\/span>\n- Topic 1<\/span><\/span>\n - First item relating to first topic<\/span><\/span>\n - Second item relating to first topic<\/span><\/span>\n - more items...<\/span><\/span>\n<\/span>\n- Topic 2<\/span><\/span>\n - First item relating to second topic<\/span><\/span>\n - Second item relating to second topic<\/span><\/span>\n - link referred to Topic 2, item 2<\/span><\/span>\n - another link referred to Topic 2, item 2<\/span><\/span>\n - more items...<\/span><\/span>\n<\/span>\n## Stats<\/span><\/span>\n<\/span>\n### Skills distribution<\/span><\/span>\n- Coding: %<\/span><\/span>\n- Mentoring: %<\/span><\/span>\n- Collaboration: %<\/span><\/span>\n- ...<\/span><\/span>\n<\/span>\n### Feedback<\/span><\/span>\nRole: my current role<\/span><\/span>\n<\/span>\nHuman friendly feedback...<\/span><\/span><\/code><\/pre>\n\n
![\"AI](\"\/assets\/images\/posts\/2025-06-17_documentation-is-cool-again\/make-docs-great-again.png\")
<\/p>\n\nTable of contents <\/h1>\n
\n
\n
\n
\n
Premise<\/h1>\n
The documentation renaissance<\/h1>\n
Why agents love good docs<\/h1>\n
Context is King<\/h3>\n
Consistency Matters<\/h3>\n
Examples Drive Understanding<\/h3>\n
No more an afterthought<\/h1>\n
![\"Claude](\"\/assets\/images\/posts\/2025-06-17_documentation-is-cool-again\/claude-code.jpg\")
\nClaude reading the CLAUDE.md file to understand that it should use a just recipe for running integration tests.<\/em><\/p>\nCLAUDE.md<\/code> files in projects. These files serve as specialized documentation that provides context, preferences, and guidelines specifically for AI agents working on the codebase. It's documentation written by humans, for machines, that ultimately benefits everyone.<\/p>\nCLAUDE.md<\/code> file to one of my company's open source projects<\/a>. This file includes everything from build commands and testing guidelines to pull request conventions and release processes. It's like having a detailed onboarding document that agents can reference to understand not just what the code does, but how the team works with it.<\/p>\n\/llms.txt<\/code> file that websites can use to provide LLM-friendly content. This file offers curated information specifically formatted for AI consumption, helping agents quickly understand and navigate website content without having to parse complex HTML structures.<\/p>\nThe new documentation paradigm<\/h1>\n
Documentation as Infrastructure<\/h3>\n
Living Documentation<\/h3>\n
Multi-Audience Optimization<\/h3>\n
My tips for agent-friendly documentation<\/h1>\n
Structure for Scannability<\/h3>\n
\n
Keep It Concise Yet Meaningful<\/h3>\n
\n
Be Explicit About Context<\/h3>\n
\n
Rich Examples and Use Cases<\/h3>\n
\n
Maintain Accuracy<\/h3>\n
\n
Final thoughts<\/h1>\n
![\"Imaginary](\"\/assets\/images\/posts\/2025-03-10_the_fine_line_between_mistake_and_innovation_in_llms\/artwork.png\")
\nImaginary artwork, combining elements of unknown and excitement, generated with DiffusionBee<\/a>.<\/em><\/p>\n\nTable of contents <\/h1>\n