fix: no more aside for me!

Author: aadishv

src/content/posts/llm-1.md

@@ -52,18 +52,19 @@ A genuine text I sent to the team is:
 
 > I keep on telling you, every time I try to touch the UI I get burnt so hard I want to quit doing frontend altogether
 
-This is the story of a recent project that I contributed to, [Dotlist](https://github.com/edwrdq/dotlib). Dotlist is still undergoing development and I have faith that we'll figure out how to fix these mistakes. This isn't meant to roast or dunk on our choices -- instead, it's a cautionary tale for how to avoid them in the future.
-
-<aside>I now have made and use <a href="https://dotlist-lite.vercel.app/">Dotlist Lite</a> for managing all of my todos and haven't ran into a single issue yet. Features like live sync and the (in my opinion :D) beautiful themes make me truly enjoy the experience, even if it doesn't have some of the sparkly features of the regular Dotlist.</aside>
+This is the story of a recent project that I contributed to, [Dotlist](https://github.com/edwrdq/dotlib)[^loc]. Dotlist is still undergoing development and I have faith that we'll figure out how to fix these mistakes. This isn't meant to roast or dunk on our choices -- instead, it's a cautionary tale for how to avoid them in the future[^dotlite].
 
 Eventually, you have to start fresh with a new codebase. This is what I did with [Dotlist Lite](https://github.com/aadishv/dotlist-lite). It's not meant to compete with Dotlist, and I'll probably only touch it sporadically from now on. I made it because I needed a good todo list app _now_, not when we figured out how to fix the UI of Dotlist. I specifically designed Lite to be much leaner while still supporting all of the important features, as well as much more polished microinteractions/UX. How I got this to happen while still using Claude for the most part is quite interesting:
 
 - I set up the project myself. I wrote out the Convex Auth boilerplate, setup shadcn themes (using tweakcn to choose), and styled primitive elements myself. The content, database, mutations, and queries, however, were left empty.
 - I made Claude port my old code to this codebase. I had an old version of Dotlist which I published as a tool on my website; it was a tiny React app which saved to localstorage. For the initial prompt, I just had Claude port the entire app (only ~600 LOC of TypeScript) to our new Convex + Vite foundation. The key idea of this is that I already understood the code, having worked on the old app for a while, so there is a very low chance of having any garbage code show up in the process. This already had the vast majority of features I needed.
 - I tuned microinteractions myself. If I didn't like a font choice or animation speed, I looked at the Tailwind classes and changed them. This is important to build up knowledge of what goes where in the codebase.
 - When I wanted to update a feature, I always asked Claude to do it. I'd review the code and test it out. If a specific part had a problem, I'd ask Claude to "simplify" and remove that part, then rewrite it myself.
-
-<aside>For reference, at the time of writing, Dotlist had 1,000 lines of (purportedly non-vibe coded) backend code and 2,500 lines of vibe coded frontend code.</aside>
+ 
 In conclusion, vibe coding is good. Until it's not. I still think the biggest advantage of vibe coding is to get an idea out super quickly -- PMs can vibe code a prototype of certain functionality instead of trying to describe it to engineers, etc. The issues start emerging when using vibe coding to actually write the majority of a production grade application.
 
 If you're looking for a simple todo app, check out Dotlist! It is still a great choice even if it's vibe coded and the team is working hard to fix our issues with the AI-generated base.
+
+[^dotlite]: I now have made and use <a href="https://dotlist-lite.vercel.app/">Dotlist Lite</a> for managing all of my todos and haven't ran into a single issue yet. Features like live sync and the (in my opinion :D) beautiful themes make me truly enjoy the experience, even if it doesn't have some of the sparkly features of the regular Dotlist.
+
+[^loc]: For reference, at the time of writing, Dotlist had 1,000 lines of (purportedly non-vibe coded) backend code and 2,500 lines of vibe coded frontend code.

src/content/posts/music.md

@@ -13,15 +13,8 @@ Apple Music, in the fullscreen view for playing music, shows an animated, flowin
 
 ![](assets/music.md/1.png)
 
-I spent a lot of time trying to figure out how this could work before giving in and actually doing a bit of research into it. I ended up going down a multilayer rabbit hole (as most of my projects end up in) to reproduce it myself.
+I spent a lot of time trying to figure out how this could work before giving in and actually doing a bit of research into it. I ended up going down a multilayer rabbit hole (as most of my projects end up in) to reproduce it myself[^ai].
 
-<aside>
-    <b>Use of AI:</b> no AI-generated code ended up the final version of this project (although tab complete through Zed's Edit Predictions was used). This task is actually surprisingly difficult for LLMs -- I tried to get OpenCode with gpt-5-mini and grok-code-fast-1 to do similar work to what I describe in the rest of this post, and they both failed. I think a big reason for this is context, which was very pervasive as the files I'm discussing are in the 12k LOC range. Even using tricks like subagents doesn't fully resolve the problem.
-    <br /><br />
-    However, I *did* use AI to help me with my research. All queries were conducted on the Google Gemini app with Gemini 2.5 Pro. I chose to go this route because the actual work with the code is very appealing to me, but doing all of the auxiliary research, not as much. Queries ranged from simple ("how does X API work?") to much more complex "explain how X effect is implemented in Y shader language, taking into account Z's implementation"). I occasionally asked Gemini to generate example code but never just pasted it in. Share links to all of my Gemini conversations will be available at relevant parts of the article.
-    <br /><br />
-    This is how I'm doing much of my coding nowadays, so I hopefully won't have to post another update like this in a while.
-</aside>
 
 This was a relatively short project: I initially started looking into it in the afternoon of October 20...
 
@@ -112,11 +105,7 @@ Gemini threads:
 
 At this point, I concluded that the fastest route to answer my questions would be to write the effect myself and then tune it until it matched the Apple Music one.
 
-I initially decided to try using WGPU and WGSL since my graphics-nerd friends recommended it (and also because Rust = ⚡blazing fast⚡), but quickly burned out after it took about 200 lines of code to draw a triangle, and 350 for a simple image. The concept of textures/fragment shaders/vertex shaders weren't super clear to me at the time, either, which probably added to the confusion.
-
-<aside>
-    For those who are wondering, vertex shaders are called multiple times to return points which form lines/points/triangles/etc. For each shape, the fragment shader is then called at each pixel (in the canvas coordinate space) to choose a certain color. Textures are used to store images and intermediary frames, and are often used paired with framebuffers.
-</aside>
+I initially decided to try using WGPU and WGSL since my graphics-nerd friends recommended it (and also because Rust = ⚡blazing fast⚡), but quickly burned out after it took about 200 lines of code to draw a triangle, and 350 for a simple image. The concept of textures/fragment shaders/vertex shaders weren't super clear to me at the time, either, which probably added to the confusion[^shaders].
 
 I decided to try using WebGL instead on a whim, which led to the fumble of the century:
 
@@ -263,3 +252,9 @@ A [chat with Gemini](https://gemini.google.com/share/3eb691bbdf01) seems to sugg
 A few future directions I could take this are actually learning WGPU (despite its verboseness...) and porting the visualization to run natively, perhaps converting the shaders via wgpu's `naga` utility, or porting it to pure TypeScript through the insanely cool [TypeGPU](https://docs.swmansion.com/TypeGPU/). GPU programming is definitely quite interesting and I think I'll explore it more in the future, perhaps implementing more complex programs such as ray tracing.
 
 As always, thanks for reading!
+
+[^ai]: **Use of AI:** no AI-generated code ended up the final version of this project (although tab complete through Zed's Edit Predictions was used). This task is actually surprisingly difficult for LLMs -- I tried to get OpenCode with gpt-5-mini and grok-code-fast-1 to do similar work to what I describe in the rest of this post, and they both failed. I think a big reason for this is context, which was very pervasive as the files I'm discussing are in the 12k LOC range. Even using tricks like subagents doesn't fully resolve the problem.  
+    However, I *did* use AI to help me with my research. All queries were conducted on the Google Gemini app with Gemini 2.5 Pro. I chose to go this route because the actual work with the code is very appealing to me, but doing all of the auxiliary research, not as much. Queries ranged from simple ("how does X API work?") to much more complex "explain how X effect is implemented in Y shader language, taking into account Z's implementation"). I occasionally asked Gemini to generate example code but never just pasted it in. Share links to all of my Gemini conversations will be available at relevant parts of the article.  
+    This is how I'm doing much of my coding nowadays, so I hopefully won't have to post another update like this in a while.
+
+[^shaders]: For those who are wondering, vertex shaders are called multiple times to return points which form lines/points/triangles/etc. For each shape, the fragment shader is then called at each pixel (in the canvas coordinate space) to choose a certain color. Textures are used to store images and intermediary frames, and are often used paired with framebuffers.

src/content/posts/robotics-2.md

@@ -57,12 +57,7 @@ Typically, these binaries are built and uploaded through VEX’s proprietary IDE
 - Documentation. PROS has actually well-documented APIs compared to the mess of VEX APIs. For example, VEX only somewhat [documented their APIs a few months ago](https://api.vex.com/) — even though they’ve existed for years!
 - External libraries. VEXcode’s tough integration with other tools makes it hard to have a proper package management system. In contrast, PROS has a robust library ecosystem with hundreds if not more packages ready to install via their CLI (another thing that VEXcode doesn’t have).
 - IDE integration. While PROS has a recommended VSCode plugin, its extensible CLI means you can code in it from everywhere (including [Zed](https://zed.dev), my favorite code editor). VEXcode can only be used from their proprietary app or VSCode extension. Also, VEXcode has _very_ weird code structure, while PROS’ is just regular C++ with cpp and header files.
-
-<aside>
-    Update 10/7/25: this is a bit inaccurate. C++ does support async, but PROS doesn't use it; all of its operations are synchronous, and threads are preemptive. `vexide` uses Rust's cooperative scheduling to have first-class async operations.
-</aside>
-
-- PROS is open-source! All of VEXCode’s APIs and protocols are closed-source (although the SIGbots team got access to it under a NDA to develop PROS) while every single bit of PROS is open-source and on [Github](https://github.com/purduesigbots/pros). This has enabled the community to do a bunch of cool things. The coolest of these, in my opinion, is [vexide](https://vexide.dev/), which is a runtime like PROS for the V5, with two major differences. 1) It supports async. But wait, C++ doesn’t have async. And then we have 2) _It’s written in Rust!_
+- PROS is open-source! All of VEXCode’s APIs and protocols are closed-source (although the SIGbots team got access to it under a NDA to develop PROS) while every single bit of PROS is open-source and on [Github](https://github.com/purduesigbots/pros). This has enabled the community to do a bunch of cool things. The coolest of these, in my opinion, is [vexide](https://vexide.dev/), which is a runtime like PROS for the V5, with two major differences. 1) It supports async. But wait, C++ doesn’t have async[^misrep]. And then we have 2) _It’s written in Rust!_
 
 
 
@@ -239,3 +234,5 @@ That’s basically all I have to say about the robot’s codebase. Hope some of
 ## Epilogue<!-- {"fold":true} -->
 
 Due to internal frustrations with how the team was being managed and the lack of focus on coding, I left the team in October 2024. As for the future of the team, they recently qualified to the World Championships by getting a design award at states. Unfortunately, their coding is in limbo at the moment as multiple other coders have left the team or are busy with other extracurriculars. As noted above, to preserve my original code (entirely written by me, with no external authors), I have cloned the repository at the time of my leaving the team in this MIT-licensed [repo](https://github.com/aadishv/HighStakes). Hope this post was helpful/inspiring/something!
+
+[^misrep]: Update 10/7/25: this is a bit inaccurate. C++ does support async, but PROS doesn't use it; all of its operations are synchronous, and threads are preemptive. `vexide` uses Rust's cooperative scheduling to have first-class async operations.

src/content/posts/robotics-4.md

@@ -46,10 +46,8 @@ When the team just got formed, I had no idea how we would play the game. I thus
 ![image](assets/robotics4/image.png)
 Note the many fancy terms here. The TL;DR is that I wanted to run as much as possible on a Jetson Orin Nano (not the Jetson Nano that comes with the VEX AI Platform) so we could have powerful hardware (aka GPU) to do cool stuff. What I eventually realized, however, is that getting this to work would require tens of thousands of lines of code. Given that this was 2 weeks before the competition, we decided to scrap this plan.
 
-<aside>VEX teams are required to maintain an <em>engineering notebook</em> to log their development journey, which also helps when getting awards.</aside>
-
 So what did we do instead?
-Here’s an excerpt from our engineering notebook about how we handled this.
+Here’s an excerpt from our engineering notebook[^nb] about how we handled this.
 
 ## The _actual_ plan
 
@@ -138,3 +136,5 @@ We ended up ranked second and made it to the finals, where we (inevitably) lost
 Overall, it was fun! We also got to ~~steal some tech~~ get inspired by some of the teams that had tried using AI. Big thanks to Chroma for being the reason we won any matches at all.
 
 Just one more blog post left for VAIRC. That one’s gonna be _very_ technical and _very long_…
+
+[^nb]: VEX teams are required to maintain an <em>engineering notebook</em> to log their development journey, which also helps when getting awards.

src/notes/agentic-envs.md

@@ -0,0 +1,21 @@
+I've recently been slowly ramping up my use of agents. The last time I tried to use agentic coding, it [spun into a mess of vibed coding](/llm-1), so I tried my best to avoid it this time. I'd previously been using the "fast iteration" models, notably Grok Code Fast 1 and sometimes OpenCode's Big Pickle (which is GLM-4.6), to do smaller tasks like
+
+* Refactor this function to use this helper.
+* Write another function in the style of this one, with the following changes.
+* Move this logic out of the function into a separate module.
+
+As I tried to do larger refactors or add functionality, though, this quickly reached its limit. This was partially due to model choice; I switched to using Claude Opus 4.5 for big tasks. However, an equally big issue was the agentic environment in which the model ran. 
+
+Agentic models, like basically all coding-oriented LLMs today, rely on some kind of feedback loop to generate correct code; it's practically the definition of "agents." In both OpenCode and Zed, LSP support is built-in, so, for example, ESLint automatically checks changed files and reports its errors back to Claude. This doesn't work perfectly sometimes, though.
+
+In a recent large-scale refactor, the model changed the schema and indexes for a commonly used table in the database, which is used by basically all of the backend. ESLint wasn't running on those files though, so the built-in LSP didn't return any errors. I thus instructed the model to run `bun typecheck` (which force-runs eslint on all files, not a subset) to find everywhere where its changes broke stuff. The typecheck command itself took around 20 seconds but eventually, after many iterations, the model did manage to get the full refactor done. Notably, even though it took several minutes, it required no input from me -- I didn't have to test the backend myself, or even rerun typecheck, because..
+
+The typecheck was all the model needed. In all of my projects, typesafety is the #1 goal[^typesafety], not only because it makes it much easier to test code, but also because agentic work significantly simpler. The agent didn't have to spin up 3 MCPs, run the Next dev server in the background, and then manually check all flows. The typesafety provided by the tools and services we used meant everything fell into place on its own.
+
+Having some kind of "end-to-end" testing system is great in a lot of cases, since it enables the model to practice test-driven development, or at least use tests directly to check its code, providing an extra layer of safety over typechecking. Here's an example of a recent project where I provided exact examples of input and output and let the model figured out the rest: [OpenCode transcript](https://opencode.ai/s/UkNhmA7i). In this case, I didn't even review the model outputs because I could verify that it passed the tests, showing how such clarity is helpful even when vibe coding.
+
+However, there are systems where tests aren't easy or trivial or fast to add, like in my initial example of a Next.js app with dozens of possible user flows. In those cases, typesafety is the best bet, and one you should make sure pervades everywhere.
+
+TL;DR: Add end-to-end testing/encourage TDD where you can; otherwise, type safety and typechecking are musts.
+
+[^typesafety]: In a recent small playground I've been working on, I'm basically just writing a Python wrapper around string manipulation: particularly, I'm using Python typechecking to create an extremely safe LaTeX creation system. The use of strict types means I can avoid footguns easily; you can't add a polygon to an expression in Desmos, and neither can you in my Python LaTeX wrapper; you can't return a boolean in functions, and neither can you there; etc. **Typesafety is good for humans *and* agents.**

src/styles/globals.css

@@ -175,9 +175,6 @@
   blockquote {
     @apply border-l-4 pl-4 italic border-gray-400;
   }
-  aside {
-    @apply border p-3 text-muted-foreground my-3 rounded-lg;
-  }
   p > code {
       @apply text-aadish;
   }