Eric Zakariasson spent several weeks running xAI’s newly released Grok 4.6 as his default model, posting his findings on X. He tested it across ordinary coding and knowledge work, then ran direct comparisons against the outgoing Grok 4.5 on identical prompts in separate workspaces. This is one heavy user’s field notes, not a controlled study: no held-out test set, no statistical claim, just an account of what changed in his daily workflow and where the model still needed supervision.
Zakariasson’s posts reference building a browser strategy game, a spreadsheet app, a Messenger clone, and launch videos rendered through Remotion, alongside two shipped projects named Cursor SDK Bridge and a slash command called /rename-chat. That body of work places him as a working developer who builds coding and AI tooling day to day, not a reviewer testing a model for the first time. His read carries the weight of repeated use inside a real workflow. It also means his impressions are shaped by that specific workflow and may not transfer to different tasks.
The change he describes is not a single capability jump. It’s a shift in tempo and clarity. Grok 4.6’s summaries tell you something rather than repeating back what you asked for, and the model stays quiet through small edits, only narrating once it touches many files. Combined with faster responses, that pulled Zakariasson away from an asynchronous style, handing off a task and reviewing a large diff later, and back toward working synchronously: ask for something small, check it, continue.
Zakariasson also tested prompting styles against each other, including whether instructions like “work very hard” changed outcomes. He found the phrasing made almost no difference. Prompt length did matter, though not in the direction he expected. A long, detailed prompt buys specificity, useful when the goal is exact. Keeping the instruction brief leaves the model to work out the rest for itself, and with 4.6 that worked often enough that a terse ask plus a stated preference usually landed somewhere useful.
The clearest result came from a spreadsheet app he built twice: once from a two-page specification, once from three sentences. The two versions came back nearly identical, until he added a single instruction asking the model to open the finished app, click through the workflows a real user would follow, and confirm that nested formulas computed correctly. He calls that one line the most useful change he made across weeks of testing. The same principle carried over to work that is harder to inspect. Asking a model to “improve the textures” on a 3D scene produced nothing useful, while telling it to “capture the current frame, list what’s wrong with it, then fix only those things” worked on the first try.
That pattern works because of what Grok 4.6 already does without being asked. Zakariasson notes the model does not need encouragement to keep working; left alone, it will keep going on a task for a good while on its own. What it lacks, absent instruction, is a target to check its own output against mid-task. Explicit acceptance criteria supply that target, turning a vague request into a loop the model can run against itself: attempt, inspect, compare to the stated bar, fix, repeat. That loop only functions where the model can actually see its own output. Websites are the easy case, since the page is text the model can read and screenshot against intent. Three-dimensional scenes and video are harder, because judging correctness means comparing a sequence of states over time rather than reading a single page.
Zakariasson’s stated reason for making Grok 4.6 his default is not that it wins any single category among the coding and video tools he tests. It’s that he now has enough accumulated intuition for how it behaves to hand off work with confidence, plus enough sense of where it needs a screenshot loop instead of a description to route around the gaps.
For teams running longer autonomous coding sessions, the transferable habit is not which model to pick. It’s writing down what “done” looks like before the model starts, so the model has something concrete to check its own work against before it comes back for review.
Eric Zakariasson, writing on X, published this hands-on account on August 12, 2026.
