Posts on Vit Salomon's Thoughts

Inventing Begins

Tue, 08 Sep 2026 21:57:36 +0200

Funny, today we had a discussion at work about how agents need to be kept on short leash or they will start inventing more than what is being asked. In the morning I tasked Grok with Prepare the MediaPool module but I didn’t have time to review its work until evening.

MediaPool is a module that we have defined in the architecture including what it should do. But we have never discussed the internal structures. Well, they were crystal clear to me and probably every developer who has done some media players before but not to Grok.

It pulled features and responsibilities of other modules and put them into this simple MediaPool. But the fix was simple. I just emphasized that MediaPool should only create / own / destroy media elements and that timing info belongs to Timeline. It figured out that I meant that those things should be removed, double checked with me on that and then updated the PR.

One more thing

Yesterday, I spoke about our rule for patch files. Today Grok pulled another trick and created stacked patch with all commits' changes instead of current state vs master. So we had to update this rule and specify it. :facepalm:

Did the pink new toy glasses break already on day 3?

First Code and Updating Contribution Guidelines

Mon, 07 Sep 2026 22:43:43 +0200

Well enough of experimenting, planning and stalling. Today was a day to actually ask for a first proper code. I started with the easiest of the components of the repository and it worked quite well. I had only a few comments to make to match the code style to something that I would actually write.

One of the things I wanted to change was also an import order. But instead of explaining that and potentially having to spend some context memory on those rules there are already tools that are better for that than LLMs. For those still wondering, prettier-plugin-organize-imports is the answer here. So after merging first real code PR. It was just a minute or two to let Grok add the plugin, format the code and approve that PR.

Raising the bar

Well, the easy part was done and to be fair even though the code matched my expectations I’d be disappointed if it didn’t. It was a clear spec and basically nothing to get wrong. Even if given to a less experienced dev.

Next up was a testing/debugging app. The architecture mentioned its purpose and we have the main component’s interface defined. But there were no other pointers given in the codebase. My prompt was:

Create the test app using React and Redux. Use Tokyo Night color palette and make it TUI like in look and feel. At the top there should be a container element for the videos, below that controls - use plain text for buttons and state of the playback. It’s a debugging app so raw data are preferrable, just nicely presented. At the bottom there should be a form for the initial configuration.

This took some time before Grok produced the code. The resulting PR was longer than what I prefer to review usually. But about a third of it were styles for that TUI effect that I wanted so it was my issue to deal with this long PR.

Not so surprisingly there were quite a few changes that I wanted to change including a complete refactor of certain part. In total, I asked for 12-15 changes. Sorry, I forgot to note down the exact number. This time however I didn’t want Grok to just blindly follow my comments so instead of stating “PR review done” I prompted:

I finished my review. Read my comments, ask about those that are not clear to you and challenge me on those that you don’t agree with. Don’t start with implementing changes yet.

The response was genuinely nice to hear. Seven to ten of those comments Grok marked as “Yeah, makes sense.” But there were five that I was challenged on. For each Grok provided a sound reason on why it thinks my request is not good and also provided a few alternatives that we could do. Once I gave Grok my decisions on those the second round of PR was prepared.

This is actually why I prefer to use Grok over other LLMs. First, it’s not glazing me for each prompt and it is not afraid to challenge my decisions and tell me why it thinks they suck.

I reviewed the new commit changes, verifying that it matches my requested changes and then I went to test the application. It looked correct, for functional part that will call the library we kept TODO stubs. So it was mostly about checking the UI. I noticed a graphical issue with some panel title getting clipped. And I could’t help but investigate. I probably could have asked Grok to try investigate and make changes but my goal is not to fully vibe code something that will somehow work. My goal is to create an app that will match my coding standards and the resulting code will be indistinguishable from my own writing. So if the bubble pops eventually and we loose all these tools, the code I’m left with is still understandable and maintainable. I found the issue within five minutes and asked Grok about it directly. And a small commit later the PR was ready for merge.

Changing Contribution Guidelines

As the last change of the day I asked Grok to add a few changes to the Contribution Guidelines to improve our PR review process. The newly added points were:

Add a timestamp to the patch file name. This way I can compare what changed easily and I keep the reference to my original comments.
Apart from inline comments I may add a general feedback at the top of the patch file.
Once I finish the PR, read the comments, ask about unclear ones, challenge me on those you don’t agree with and do not start implementing changes until we agres in our discussion.

I really enjoyed that challenge part in the last PR so I want to keep it. It feels a lot more like an actual PR discussion between author and reviewer, many good ideas came from those so why would I want to avoid them.

Building an Open Source Library With an Agent

Sun, 06 Sep 2026 15:31:08 +0200

For quite a few years now I’ve been carrying a concept of a library for synchronized playback in my head. But unfortunately I never had time to sit down and start creating. There’s always been something of higher priority, not enough energy or just real-life happenings.

But people seem to use agents to vibe code their apps and put them into various stores. I don’t know how much code those apps contain generated vs. hand-written. What’s the quality of that code, how is it with maintainability… Even linux core now accepts some amount of generated code.

So I got an idea, why not to try to create that library that I wanted for so long and learn to work with agentic workflows and LLM generated code at the same time? And document it as well :-)

The Beginning

On purpose, I didn’t start with looking into how you manage your work with agent and how others approach it. I decided to go for it blind. I had a very little experience from the same day using agent for a task (see my post about my linux journey) and I used web chat interface for various LLMs before.

I created a folder, an empty repository, added my prettier config and started writing a markdown file of what I want to build, how it should work and I ended up with about 50 lines of unstructrured points.

Then I spawned my Grok (version 4.6) and asked it to read through it. And ask me questions about things it didn’t understand or where it saw some gaps. Ten minutes later I received 32 questions that all made sense. So I put those questions into a new document (QaA) and started writing responses to all of them. I got quite surprised how deep some of those questions were. I took some time answering those but mostly I knew how to deal with various of those situations that Grok presented.

With all the questions answered I prompted it to read both documents again and re-iterate and present another set of questions where decisions weren’t clear or we have gaps in the spec. Ten minutes later 25 even deeper technical questions were waiting for me. I’ve read through them but since I was already two hours into the progress, I decided to take a break before answering them to avoid focus tunnel and also to think how I want to cooperate with Grok on contributions to the repository. Walk in the nature is perfect for things like these.

Old Fashioned Approach

Full of energy and new ideas I sat down, wrote responses to those 25 questions from earlier and also added AGENTS file and CONTRIBUTING guidelines for Grok. The main rules are:

never commit to master
never push to remote
never publish anything to npm

For work I have setup and explained it an old fashioned approach. It makes changes in a branch with conventional naming based on the task I give it. Once it’s done it creates a “pull request” by presenting me with a patch file. I then review the changes and leave inline comments in that patch file, plus general feedback at the top and return the steering wheel back to Grok. It is then supposed to implement my requested changes and once ready present me with a new patch file. Oh how I wish I could write inline comments like this using GitHub CLI. I still need to rethink this approach so I could keep history of previous comments because I loose them for now. Fortunately, the most amount changes I have requested were three so I just checked the last commit Grok created with my requested changes.

Once, I finished setting these new rules up and I tasked Grok to read them and start following them. It’s first task was to compile the initial ideas document and two QaA files into a structured architecture file. Which grew to whopping 450 lines from the initial 50. There was also a part of the architecture that Grok wanted to do but I didn’t like his proposal and we decided to keep it for later.

Day 2

I didn’t get much sleep, mostly because my brain just kept thinking about that feature we didn’t specify. Anyone’s elses brain also refuses to shut down in the night and even though I was pretty tired, it kept me awake. Later in the day I wrote about 30 points for that feature and how it should interact with rest of the system. It also required some changes to the interface and followed with two rounds of ask me and I shall clarify. After that, Grod was tasked incorporate this new behavior into the architecture. Followed by a PR that set up the skeleton for packages that we agreed upon.

As it sits now, there’s a 550 line of architecture documentation and the most basic skeleton of a monorepo. I still have to see a proper code that it will generate but for now I’m pleasantly surprised. My plan is that all the generated code will have to meet my criteria for high standards. I won’t be satisfied with a huge code that somehow works and no-one understands it properly. Let’s see what the next days of actual coding will bring.