The article very much resonates with my experience past several months.
The project I work on has been steadily growing for years, but the amount of engineers taking care of it stayed same or even declined a bit. Most of features are isolated and left untouched for months unless something comes up.
So far, I managed growing scope by relying on tests more and more. Then I switched to exclusively developing against a simulator. Checking changes with real system become rare and more involved - when you have to check, it's usually the gnarliest parts.
Last year's, I noticed I can no longer answer questions about several features because despite working on those for a couple of months and reviewing PRs, I barely hold the details in my head soon afterwards. And this all even before coding agents penetrated deep into our process.
With agents, I noticed exactly what article talks about. Reviewing PR feels even more implicit, I have to exert deliberate effort because tacit knowledge of context didn't form yet and you have to review more than before - the stuff goes into one ear and out of another. My team mates report similar experience.
Currently, we are trying various approaches to deal with that, it it's still too early to tell. We now commit agent plans alongside code to maybe not lose insights gained during development. Tasks with vague requirements we'd implicitly understand most of previously are now a bottleneck because when you type requirements to an agent for planning immediately surface various issues you'd think of during backlog grooming. Skill MDs are often tacit knowledge dumps we previously kept distributed in less formal ways. Agents are forcing us to up our process game and discipline, real people benefit from that too. As article mentioned, I am looking forward to tools picking some of that slack.
One other thing that surprised me was that my eng manager was seemingly oblivious to my ongoing complains about growing cognitive load and confusion rate. It's as if the concept was alien to them or they could comprehend that other people handle that at different capacity than them.
> One other thing that surprised me was that my eng manager was seemingly oblivious to my ongoing complains about growing cognitive load and confusion rate.
Engineering managers in my experience (even in ones with deep technical backgrounds) often miss the trees for the forest. The best ones go to bat for you, especially once verifying that they can do something to unblock or support you. But that’s still different than being in the terminal or IDE all day.
Offloading cognitive load is pretty much their entire role.
Absolutely not. Learning has been to experiment with the things until you form a effective mental model of the thing. Writing things does ab-so-luetely nothing except make you feel good in the moment. Just like listening to a lecture without engaging with the subject matter deeper.
Writing things down is important for organisational persistence of information but that is something else.
I think that recording dialog with the agent (prompt, the agent's plan, and agent's report after implementation) will become increasingly important in the future.
You will also add a markdown file to the changelog directory named with the current date and time `date -u +"%Y-%m-%dT%H-%M-%SZ"`, record the prompt, and a brief summary of what changes you made, this should be the same summary you gave the developer in the chat.
From that I get the prompt and the summary for each change. It's not perfect but it at least adds some context around the commit.
Isn’t the commit message a better place to add what and why? You might need to feed some info that the agent doesn’t have access to “we are developing feature X this change will such and such to blah blah”. The agent will write a pretty good commit message most of the times. Why do you need a markdown file? Are releasing new versions of the software for third parties?
Cheaper and faster retrieval to be added to the context and discoverable by the agent.
You need more git commands to find the right commit that contains the context you want (either you the human or the LLM burning too many token and time) than just include the right MD file or use grep with proper keywords.
Moreover you could need multiple commits to get the full context, while if you ask the LLM to keep the MD file up to date, you have everything together.
How often, in your experience, do people read those auto-generated markdown files? Do you have any empirical data on how useful people find reading other people's agents' auto-generated files?
Agree, but current agents don't help with that. I use Copilot, and you can't even dump it preserving complete context, including images, tool call results and subagent outputs. And even if you could, you'd immediately blow up the context trying to ingest that. This needs some supporting tooling, like in today's submission where agent accesses terabytes of CI logs via ClickHouse.
I've had some luck creating tiny skills that produce summaries. E.g. a current TASK.md is generated from a milestone in PLAN.md, and when work is checked in STATUS.md and README.md are regenerated as needed. AGENTS.md is minimal and shrinking as I spread instructions out to the tools.
Part of my CI process when creating skills involves setting token caps and comparing usage rates with and without the skill.
Honor culture is what happens when there's no reliable institutions or evidence, so people have to defend reputation themselves - usually with retaliation and interpersonal violence. Always-on cameras are the opposite idea: enforcement moves outside the individual, which is basically how honor cultures stop being a thing.
The Quantum Thief series by Hannu Rajaniemi depicts a society where the protection point in "smart glasses" is addressed by making shared info opt-in and handling that centrally (vulnerability of which is a major plot point), so people see a non-distinct blob instead of a person if they don't have access. There's more to it in the books, but I won't spoil, I highly recommend reading these instead.
I experience this all the time and UX is absolutely one of culprits here. The workaround works, but UI doesn't nudge you to adjust the value, it just throws an opaque error. It's so obvious to me that even such a simple thing as saying "Try smaller radius" would make things more obvious, or even better - have a button in that error to "Set radius to largest valid". Saying that "but it's cause by OpenCascade" is a thought-stopping cop out. If there's a manual workaround trick, you can always integrate that into UI, but not doing so is a choice.
The workaround mentioned isn't a magic solution, it fails in a bunch of more complex cases too. Chamfers are a complicated operation and predicting valid values across of the operation in order to set a maximum value is, as far as I'm aware, in a similar region of difficulty. It would also be unfeasible in many cases to attempt the actual operation across a wide range of values. It's not so much a choice as just being hard to do.
MJ is awesome, but I recently discovered this another treasure trove of a YT channel that has only 5k subscribers and covers topics MJ has less focus on, like reverse engineering or surfaces: https://www.youtube.com/@DuyQuangDang/videos
I think it would be really cool to have a Windows 98 running in browser and an agent to proxy all interaction to real desktop and web:
* It proxies web sites and optinally modifies them to look era-appropriate.
* It can generate missing native apps as shims to apps on your host or web sites. Like, cmd that's actually a pwsh. Or VSCode that looks like Borland C++ Builder.
* Streaming media like Bandcamp or Spotify inside a real WinAmp 2.x.
Ha! That's a cool idea. Regarding proxying web sites: that is essentially what this is, but the agent is a "browser proxy" so the web requests go through a browser and the rendering happens on the browser in the server it's on.
BrowserBox actually has a crazy win9x compatibility mode that opens an IE6 compatible client. The issue with native Win 98 browsers is not so much the web content support (which is, admittedly, very basic), it's the lack of modern cipher suites in HTTPS, so an actual proxy would need serve everything HTTP.
For "era-appropriateness" you could add a Chrome extension to BrowserBox that gracefully downgraded all pages to look antique but doing so in a way that can interface with DOM and JS directly - a fine-grained level of control is where browser-based approaches have advantages over rewriting-proxies.
In the past I experimented with running Electron apps heedlessly on servers and have BrowserBox connect to the apps so you could stream these apps. However it was limited to Electron (or other browser-as-render-engine type GUI apps). It was tricky tho due to Electron quirks and never that compelling for me.
FYI greek has a good introductory course by Language Transfer, from which you can graduate to textbooks (available from rutracker) and ChatGPT for practice and OCR. I also maintained decent retention by converting everything I learned into Anki cards. Living in a greek-speaking country helps, but only when you are forced to communicate in EL or when you explicitly ingest new words/phrases from what you read around. Before that, I used Duolingo for the same purpose, had issues keeping the streak up and understanding the material (this was early ChatGPT era, though).
Tried the game and it was pretty good! The polygonal look fits really well, reminds me of games by Introversion.
A couple of suggestions:
* Add gamepad support, there's a browser API for that.
* Things are way too tiny compared to VS running on same screen. It was often hard to precisely maneuver and distinguish between entities.
On a side note, I'd definitely play a mix of fl0w/Spore with VS.
Gamepad support is a good idea — I’ll look into the standard Gamepad API.
The small scale is partly a trade-off for mobile + keeping everything very lightweight (single 85KB file), but I agree readability suffers and I should improve sizing / contrast.
Also +1 on the fl0w / Spore + VS vibe — that’s very close to what I was aiming for visually.
Thanks for the feedback — I’ve just pushed an update with larger entities and better visual scale.
It should be live now (a refresh should pick it up).
The engine was rewritten for performance (in C++?), but the designer is fluent enough in Phaser/JavaScript that they continue using the original engine for testing new features.
Not if your manager doesn't know what you are really capable of and your coworkers keep at about the same pace as you. Manager may get some portion of that productivity, but who says it has to be everything?
The project I work on has been steadily growing for years, but the amount of engineers taking care of it stayed same or even declined a bit. Most of features are isolated and left untouched for months unless something comes up.
So far, I managed growing scope by relying on tests more and more. Then I switched to exclusively developing against a simulator. Checking changes with real system become rare and more involved - when you have to check, it's usually the gnarliest parts.
Last year's, I noticed I can no longer answer questions about several features because despite working on those for a couple of months and reviewing PRs, I barely hold the details in my head soon afterwards. And this all even before coding agents penetrated deep into our process.
With agents, I noticed exactly what article talks about. Reviewing PR feels even more implicit, I have to exert deliberate effort because tacit knowledge of context didn't form yet and you have to review more than before - the stuff goes into one ear and out of another. My team mates report similar experience.
Currently, we are trying various approaches to deal with that, it it's still too early to tell. We now commit agent plans alongside code to maybe not lose insights gained during development. Tasks with vague requirements we'd implicitly understand most of previously are now a bottleneck because when you type requirements to an agent for planning immediately surface various issues you'd think of during backlog grooming. Skill MDs are often tacit knowledge dumps we previously kept distributed in less formal ways. Agents are forcing us to up our process game and discipline, real people benefit from that too. As article mentioned, I am looking forward to tools picking some of that slack.
One other thing that surprised me was that my eng manager was seemingly oblivious to my ongoing complains about growing cognitive load and confusion rate. It's as if the concept was alien to them or they could comprehend that other people handle that at different capacity than them.
reply