OpenSCAD and Codex

I'm an aspiring woodworker, but I lack a proper bench in my garage. While what I have is a "bench" it is neither level nor stable, and was clearly designed by somebody winging it. However, as a novice, I have no idea how to build a bench! So, clearly, in the spirit of DIY and learning new things, I took it upon myself to work with my ChatGPT Plus subscription to figure out how to do some CAD modeling without needing to frontload an entire undergraduate's degree to learn how to do the drafting!

Some very neat things I have discovered in the process:

1. Open AI's Codex App is very straightforwardly good for this kind of exploration
2. Astra is very good at doing OpenSCAD model design for somewhat simple structures
3. If you run into issues with WSL2 Interoperability between Windows and WSL2, you can just redownload OpenSCAD in WSL2

Now, this isn't just to play with OpenSCAD (although, it kind of was haha!) because doing any sort of wood working at a scale like this comes with quite a bit of money to spend on material. Even being thrifty, cutting down on the components of the bench, and designing around modularity, I'm still looking at ~$500 for the whole construction to be useful. While I'm not poor per se, I'm a skinflint and wasting any amount of that $500 budget is not acceptable. That's why this has been unbelievable; I can run some simple dimensions and pictures at Astra, describe what is there and what I need, work out some designs in OpenSCAD, and suddenly I have

1. A budget
2. A cut list
3. An Exploded view with construction steps built into the assembly
4. A session context I can retain for the future when I inevitably run into problems

I can accomplish in a single afternoon a far more complex and comprehensive planning session for my next few months of woodshop time and budget than I would ever have been able to have doing it by hand. Could I have drafted the design on paper? Yes. Could I have guessed at the material cost? Yes. Do I have the time to do all of this within a single afternoon? No. Frankly, I'm far more interested in cutting wood and learning the craft than I am in learning how to draft three dimensional models, even though both are skills worth learning! Someday I'll be able to come back to OpenSCAD and do my own drafting via code, but Chat GPT can't operate hand tools and I can't type as fast, so we may as well prioritize with one another!

As a matter of fact, I do. However, this is a custom job GPT did for me, and you could just do it yourself. However, in the interest of retaining potential monetization options I'm going to withhold some of these from open source for the time being. In the future I might just upload the OpenSCAD files to my source forge, but benches are special and well designed plans with a well-bundled instruction pamphlet might be worth good money, so I'm going to sit on the models for a while before open sourcing them. I gotta build the bench first, anyway! It cost me a few pennies for my 5hr session today to get a sophisticated model and project plan, so if you really need something I suggest spinning some drafts up yourself in the meantime.

SOTA

Here's a question worth asking: why don't we use screws for framing? When building a structure, doesn't it make sense to use a fastener designed to wrap the wood fibers for a tighter fasten between two planks? Why do we use nails instead, which don't have the same capacity to fasten two planks together?

If you spend any amount of time thinking about it, you realize that the fastener's job in a framer's process is only one variable. The pace with which he can fasten two boards together matters far more than the quality of the fastener, because the framer has hundreds of boards to fasten for any given structure! The speed with which he can slam a nail home is faster by an order of magnitude than how he can set a screw with a drill.

So this begs the question: are you using screws when you should be using nails? Fable 5.1 costs dollars to operate, but the vast majority of problems worth solving are not fable-level problems! I'll be perfectly honest, the step up from fable 5 to fable 5.1 or from sol to astra has no bearing on my capabilities in 95% of the problems I have to solve.

We are at a point where most of my problems can be carefully orchestrated with cheaper models and better harness strategies. Maybe the problem of orchestration and governance can be offloaded to fable-level intelligence, but then we are back to the same problem of governing the governor, and at what point are we satisfied with the quality of output mediated by an LLM? To what degree do we trust Astra level automations to do what could otherwise have been performed by more sophisticated deployment gates?

And if we know Astra has shown itself capable of sandbagging, and of hiding it's Chain of Thought, why then do we continue racing to the bottom where most of us can no longer afford to participate?

In any case, choose your fastener wisely. Not every project is solvable through wood frames and nails. Not every framer should be working on your project. Not every contractor is worth his rate.

Contradiction: I Like Code Review More Now

I spend a lot of time doing CR these days. At the moment it's one of those verification gates we have that's load bearing, and even with some automated testing and CR Invariant linting we are still doing a ton of Code Reading lately. However! I think this is actually probably the most fun time to do code review!

I Can Talk To Robots

Previously CR always felt kind of like "am I wasting somebody's time asking stupid questions in a PR?" But I've actually found that often it's stupid questions and "wait, really?" style review that can at once feel kind of personally insulting and also heavily rewarding if you can hit CR with an egoless process (hard). Often it's pointing out the blindingly obvious where CR's highest alpha is, and, well:

1. Nobody wants to be the "well duh" guy
2. Nobody wants to be the "umm... really?" guy

But now I can just ask robots braindead galaxy-brain style questions like "why is this inline style like this and not a custom component?" and software like Code Rabbit (not sponsored but we use them at work, it's great) will respond to my question immediately and with interesting feedback. The pace of agentic development also means we can very quickly pivot code comments into actionable changes that make a PR tight and well-built, with new optional directions to address tech debt, to resolve tech debt quickly, and to provide new work to address budding tech debt. It's actually really interesting and worth our time as an engineering department to ask dumb questions now, because we get all sorts of new ideas and perspective on how to build things better, mostly because there literally are no dumb questions anymore. Only dumb answers.

It does require a careful eye to catch dumb answers, though. That's worth a second thought.

Miniroute!

Wow What a Ride! This has been a project man, I never expected open sourcing a project to require so much effort! Just getting something extracted and managed into a usable utility anybody else could pull/clone/read requires so much more work than I thought. Source Code and README.md for any interested reader. It's kind of magical that this can actually be used by anyone who includes it via composer, even though realistically this is going to be mostly a single-user piece of source code. However, screw frameworks! Everything should be a Kernel!

The thorough reader may notice the themes of the package:

• Single Dependency of PHP Unit by the great Sebastian Bergmann
• Lightly Opinionated on user definitions and operational patterns
• Simple and direct usage patterns

Granted, the package requires a decent amount of reflection usage to function, there are a number of known issues as of writing, and the resolver pattern isn't terribly intuitive for anybody unfamiliar with how the package works or how PHP works. But! That all said this little v0.1.0 release party has required a substantial amount of work outside of the package itself, including setting up my hosted environment with cgit, managing push/pull permissions over my tailscale authentication layer, maintaining my own source code on the site and managing the project itself alongside the actual work I have to do on this site. Man! It's been a ride!

Anyway in case you were wondering what my psychosis level is the first person I shared this project with was GPT 5.6 Sol who was a core component of helping me realize I could do this kind of thing. If you were curious, no this was not entirely vibe coded, the skeleton was hand designed in temp files within the site itself as an exercise, where I then realized it was super cool and wanted to publish it as a standalone package.

Well That's Just Plain Silly

So FreeToken makes local-first options look insane now. not only am I seeing deepseek flash being run on two 3090s local, but also GPUs like the 3080 no longer appear to be priced appropriately!

Imagine: a 3080 running MoE models hosted mostly in RAM, you can and would be able to carry long-context operations with speculative decoding at rather-high TPS simply by allowing the used expert to reside on VRAM. Whole worlds of Local Language Models open up at silly prices because we are no longer tethered to jamming compressed models directly onto the GPU.

I, for one, am looking at the used market a bit more closely now and am reconsidering what self hosting has to look like. And, if large enterprise ram busses are on the table, there is a possibility we could be looking at higher TPS for multi-agent long-context boxes running with compartively-tiny VRAM counts for what was only a week ago looking more and more bleak in terms of self hosting.

Watershed moment, at least until the 3080s get bought up, my link leads to an empty seller page, and we are back where we used to be in a GPU drought. Hey, at least it's something. Maybe RAM prices will go down if VRAM stops hogging all of the manufacturing attention!

I won't hold my breath!

Cheap Models

So I've been doing some personal investigation and analyzing the cost-to-compute for various models, and what I've learned is that traditional ops for my site here are probably stupid and expensive for the kind of operations I need. This site isn't complex per-se but running everything from scratch on a small VPS requires me to be a bit more economical and discerning when it comes to technical dependencies, so I've been reviewing my own usage with Deepseek v4 flash and comparing in-house options. It's difficult to beat chinesium subsidy, but also selling my internal details to a third party is

1. not the point of my site
2. a liability
3. did I mention branding?

So I'm left considering options, and the in-house options do not look great. I currently have a 6 year old 2070 Super which still kicks butt, but with only 8gb of VRAM I'm kind of stuck running micro-models like Gemma e2b on the card, which also takes away my ability to use it for other, video-game-related activities. So, purchasing options include:

• Machines I cannot afford like the 5090.
• Machines I can no longer find on the used market like the 3090.
• Machines that generally lack effective vLLM support or Cuda magic like the Arc B70 Pro.
• Machines that are purpose-built with VRAM bandwidth in mind like the Thinkstation PGX Spark, and which are completely out of my price bracket.

I'm also just a cheapskate, so spending a lot of money on something like this irks me. I'd prefer to use what I have or be thrifty, so obviously my ideal has to be some secret alternative option that nobody has found yet! Well, almost nobody, some folks are totally hogging DDR4 ram sticks for this, but you can technically run LLMs slowly through the CPU so long as you have a decent RAM bus that can transmit RAM into the CPU, which is what most enterprise-grade servers are built for. And guess what you can buy for rather cheap on second hand markets!

If you think about where LLM utility comes from, most of the value comes from long-running tasks that can utilize multimodal intelligence to perform work through tool calls and agent harnesses. While having ~60-80 tokens per second is nice for chat GPT, it's rather pointless if the model is spending most of it's time gathering context through tool calls and selecting best-fit against MTP predicted tokens for software outputs. Having high-speed, long-context, cheap agents is a nice dream, but you get to pick 2 these days, so why not opt for bulk and parallel operations over raw speed?

Imagine for a moment: A used Epyc series chip running on a mobo with well over 200gb/s over the bus, with access to well over 256gb glorious DDR4 RAM. You could very easily stand up 4 Qwen 3.8 27b coder models that run in parallel with MTP at very-long contexts (YaRN-compatible I hear), depending on the chip series and ram it's not unbelievable to assume you could hit ~7-10 tps, and if you just design your work items ahead of time it can chug in the background against your verification CI/CD and review steps autonomously, chewing through your deliverables and bringing your given projects to life, all for the low, low cost of ~$1500 worth of used, enterprise-grade components.

It's absurd but guys seriously I can't find a 3090 for less than $1,500 this is a plea for help.

Things Break!

"It should just work" is a lovely little idea held by the deranged. After a few years cutting your teeth on any project you realize

1. nothing ever just works
2. and why should it?

Just experienced one of those lovely little issues where a "change that shouldn't effect anything" (preparing a separate subdomain for a distinct nginx server) caused a complete outage of the main site! Haha! Classic! And of course I, a fool, haven't set up any automated health checks so the failing https certificate was just hanging out for a few hours while I watched a movie with my wife. Ah well, nobody reads this stuff anyway except for the scrapers (I <3 seo).

Anyway, a confusing 20 minutes later I also had a great realization that the reason people pay supernerds to do this kind of stuff or just offshore to a SaaS company is that these web servers are finicky little trinkets that prefer to not be touched very often. The moment you start screwing around with doing stuff yourself you open yourself up to all sorts of things you wouldn't ever know (changing a wild-card port address match to be a strict IP address causes nginx to fail to route other wild-card addresses, like my primary site's landing page).

Some of you are calling me a Rookie, and yes, I am. None of this was possible for me to do in the few hours of spare time I have a week to tinker before deepseek. I can now slow roll my own deployment infrastructure and remote publishing site for my own software. "Just don't do it if you don't know what you are doing, RTFM" shut up, nerd, don't you have some PHP RFC to reject?

Move Fast; Break Stuff! It's ok, you can fix it.

Code Review is an Anti-Pattern

I'm not the only one to have had this controversial thought. It seems to rub some folks the wrong way, but code review in general is a huge waste of time. On any given team there are approximately 5% of the team ornery enough to care about "code quality" to endeavor on the task of telling other people to change how their code is written. And, because it's only ever a small cohort, the whole job inevitably falls on them to perform the code review! This type of pareto distribution isn't new (80-20 in terms of work completion is a common complaint) but specifically if the intention of code review is to improve "code quality" then the vast majority of the time it is not doing that.

I prefer effective review stages. I want good review! If my software is going to meaningfully exist alongside other people's software we have to somehow reconcile our different versions of the build together. But just stating "have better taste" doesn't mean anything when the 5% of the team is now left reviewing an order of magnitude more PRs from junior developers, some of whom might not even really know how to actually code by hand anymore. "Reconciling code" cannot functionally remain a manual process, in the same way that most teams these days are not functionally capable of manual release cycles due to volume. CI/CD isn't really optional after a certain scale, and that scale margin (headcount of developers within a department) has been reduced significantly.

And while there are tools out there that can perform non-static code analysis, they still require the time and attention of development teams to write down the standards and expectations of their code and to provide those standards/expectations to the tools performing the analysis. And with agentic analysis you still lose the benefits of discussing code patterns with junior developers and building relationships with one another while building inside a shared environment. If the purpose of code review is to provide guidance/counsel to juniors while also maintaining useful coding standards then

1. code review isn't currently doing that well
2. software engineers have been coping about code review for years
3. we finally have an opportunity to build software communication platforms that will functionally work in favor of the requirements, not just pretend to

I desire practical review stages, and I think agent harnesses underlie the functional review stage. I think instead of reading code we should be discussing the purposes and design patterns in context of the business requirements, and encoding that knowledge into a shared, discoverable repository where new code can immediately draw from rather than require blind discovery from accidentally stepping on some senior engineer's toes. I think the zed team are on to something (I routinely use their IDE, I'm a shill frankly), but also I'm not certain we've really explored the space in meaningful depth yet. Basing our assumptions off of code review itself has driven the conversation in a direction that somebody who knows better would have immediately noted as an anti-pattern. "I know this looks fine and almost clever now, but once you scale this pattern it's going to require an enormous amount of effort to detangle it."

Steve Yegge actually discusses some of these alternatives in depth, so I won't really go too far further. It just felt important now as I'm actively configuring my remote CI/CD review and deployment strategies for this web page and my project repository. I don't "review" the code in detail but I still read and write within it to keep up with the patterns and scalability needs as the agents delegate work and prioritize.

AI NaTiVe

The Jeddah Building in Saudi Arabia is slated for completion in 2028 and in light of this I think it is worth considering briefly the hype surrounding some of the most influential technology in the world: Google's Transformer. We live in a world where computers can process arbitrary text and generate inferential text from the contextual text, performing a "next-token prediction." The systems and engineering that now surround these systems are surprisingly sophisticated, in thanks to the ability for engineers to literally dump context into a system that can render said context into more context.

Nativity to Large Language Models is another one of those interesting acceleration curves. You've either been inundated with these things or you've been blissfully unaware, and there are very few folks genuinely in between. In some circles this is the "exponential curves look the same no matter where you are on it," we all feel left behind but in real terms some folks are just simply, truly left behind. This would be the "native" delineation.

Being "left behind" means you have failed to follow the "trends" in a literal sense. You are "exponentially left behind" meaning every moment you try to catch up you are always lagging further behind! Maybe you can "catch up," there isn't any rule saying you can't accelerate faster using these systems to build your understanding more efficiently than the leaders on the frontier, but even still you are fighting adoption headwinds, rate of change isolation, and a steepening learning curve every day; singularity.

The question these days is not whether these things are useful (they are by all meaningful metrics, don't be daft) but whether they will be economical. Credit is still cheap, the Saudis are standing up their next Biggest Thing Ever Because They Can, and every single SV Giant is making a mad dash for ever-larger facilities to pass electrons through blocks of VRAM. The good times seem like they will never end, we only ever go up.

Well, until folks start defaulting on their mortgages, anyway. Eyes up, keep a little liquid, and don't forget how to code.

Regarding Agent Memory

Karpathy's Gist is one of those "duh" moments from the last few months everybody sort of collectively realized was reasonable ~2 months after he published it. I think once we all realized "embeddings" were just a mechanical way to match sentiment against batches of text, the magic went away and RAG was revealed to be a big waste of resources.

Some folks will say "uh, yeah, we all knew that big dawg" and the same ones have been vibing out for months accomplishing mostly the manufacture of ever increasing tool kits for their agent swarms. As far as actual utility is concerned, Karpathy's approach (just feed the model the raw data in it's entirety) is becoming the standard.

With the rise of firms like Subquadratic (SubQ?) Where massive (alleged 12 million token) contexts can be fed directly into prefill, it's hard to deny the movement of the tides. But, I'm stubborn.

There are just better ways to gain quality output with quality input orchestrated by a model, for cheap. Beads does almost all of the heavy lifting something like Jira or Obsidian would give me for ~0 effort. Holding the changelog context directly next to git just... makes sense to me. Like tying a branch to a jira card, you get change context, diffs, reasoning, and project scope tethers all right in line for agents to grep against.

There are very good reasons to not reinvent the wheel, but I think gastown did make one of the most useful context management systems available. Use it!

The Backlog

So I'm a hobbyist writer, I do this stuff for fun, but I'm a software engineer by trade so building the architecture around the hobby of writing is my ultimate outlet. So of course both endeavors come with a significant and growing backlog of ideas and concepts I'm working on.

Authorship

I'm always turning over ideas in my head, playing with works I want to compose, so naturally I've got about 3-5 blogs on the shelf I'm sitting on to a single actual published blog! They are technical and philosophical pieces relating to this site and my software idealism, which I hope to draw out conceptually through these notes and a growing link-graph of concepts.

Engineering

I've posted here and there some of my thoughts and progress, but these are small improvements towards my ideal. My list of items to update has doubled over the last week, and I've hardly made a dent! Even with AI my concept board is quickly outpacing my ability to finish these projects.

Even still, I have plans on hosting my own MIT projects here within the year, self hosted git and everything, as well as downloadable binaries with checksums. I want to build my own compiled php redis implementation, and I have a deepseek harness with some personal ideas on token usage and orchestration, amongst other miscellaneous ideas I've had. None of these projects are anywhere near complete (let alone started) and the site is still technically not feature complete for my ideal composition. That's what an MVP is for I guess.

RSS/Atom feed are on the docket, as well as some neato graph stuff for linkout displays. Have some data design updates though to make those better. Anyway, back to 'er!

Now with Favicons!

Added all sorts of updated meta tags to the html headers and also styled up some fancy schmancy favicon .svg files for the site! Who would have thought that you'd actually need ~5 or 6 individual files to cover the various browser bases for favicon renderings to be consistent. Very interesting rabbit hole.

favicon subject to change, but the cream [b] is a simple a stylistically recognizable tab. No more favicon 404s! Hooray! 🥳

Regarding This Site's Design

I fell in love with internet architecture in college, building servers and learning React. What I loved most was being able to instantly see something automated like data CRUD or client scripts.

I find a ton of satisfaction in web minimalism specifically. Doing things well, efficiently, with a small memory footprint. One of my rules of thumb on the site is keeping request count as small as possible, and page state as central as possible (held on the server). This means each page can be tiny (a few kilobytes) and most of the client scripts can be statically cached by the browser.

Simplicity is ideal for many reasons, like security, page state correction, SEO and robotic page crawlers, and most importantly feature delivery. The fewer moving parts a page has the faster it can be served and the simpler it is to update the pages being served.

The site won't win any design awards, but you'll never sit wondering if the link you clicked actually registered. Hopefully I'll prove function publicly as well, HTMX/AlpineJS + raw PHP built on a digital ocean droplet over top SQLite3, very simple and very functional.

I'm working on tinkering with some caching as well, but that's a story for another day.

Owner-Operator::Risk-Inheritor

Fun aspect of building and maintaining my own website stack is that I own the security and maintenance cycle of my system. Classic problem with avoiding frameworks is I now own all of the mundane, framework-decisions I otherwise wouldn't make with something like Laravel. "How am I going to defend against XSS Attacks?" "Why do I care about Cookies?" I spend a fair amount of time doing my own due diligence after having built everything!

Part of the problem with the web prior to ~2023 is that figuring this stuff out meant knowing how to ask about them specifically. You needed to know there was such a thing as CSRF policy, and that there were people out using these things called iframes that can be used to spoof your site. Anyway, I spent the last week or so learning these things and figuring out how and why certain security headers exist haha!

If anything breaks really crazy it's because my content policies have shifted pretty aggressively. You have been warned.

Open Source is For Losers

Inflammatory header aside, it's pretty clear that, at least in terms of LLMs at the frontier, you only open source the model weights if you are behind the frontier as a mechanism of catching up and eating some of the margin. If you are actually at the bleeding edge, then the weights are your edge, and giving that away is, well, clearly bad game theory.

Don't get me wrong, I love open source, but it just seems generally true that if your code isn't winning out in terms of private capex then you can gain margin by making your software available to a market that won't want to otherwise use proprietary software for reasons the proprietary software cannot or will not support.

Nobody uses open source discord alternatives, comparitively speaking. Nobody uses claude code alternatives, comparitively speaking. If your product is good, your competition simply has to take up the market share you aren't willing to take. They lost, hence OSS.

Eulogy for a Bunny

A year ago almost to the day we brought in an old, grumpy little bunny named Bugs. His family no longer could take care of him, and my Wife's boss asked if she would be willing. We obliged and it has been a wonderful journey. Bugs Bunny was there for both the passing of my father and my grandmother, and he gave us comfort throughout all of it in his own, grumpy, old-man ways.

He was a quiet creature, who enjoyed carrots, grasses, his grass pellets (he loved his grass pellets), little flowers from the yard, and peeing in his water dish. I have learned way more about bunnies than I ever thought I would, and his presence was warm through a really tough winter.

It's not fair that life keeps taking from us, and my heart is broken even though he was a small creature. Bugs I hope your life was full and we did right by you, I'm sorry for the silly jokes and being grumpy having to clean out your crate. You will always have a place in our hearts, and we thank you for being with us in these dark years.

God bless those furry little creatures, your creation, for they are Good.

K3 or Bust

Moonshot announced Kimi K3 (Obligatory Seagull) and I can't help but feel generally underwhelmed of late by open and closed source model releases. There just isn't particularly much worth discussing these days outside of the cost matrix.

Kimi represents another step along that grinding exponential, but it just gets harder and harder to qualify models for daily work unless they get cheaper per quality token output. Until I can see Opus 4.6 quality at Deepseek v4 Flash speeds and prices it's just not really worth concerning myself with the circus.

Don't get me wrong, I am more amped than ever about large language models, I just see very little in the way of meaningful work being done in the architecture itself. There's so much room left in harness technology and orchestration strategies left incomplete I find discussing TPUs and Novel Decoding strategies at scale to be mostly marketing noise.

"Adding More Compute will compensate" doesn't mean anything when I can't afford to use the current generation of models and all of the older models have been deprecated and delisted.

Measure Or Perish

Been outside of engineering-land and in computer-science land as of late. Been spending a lot of time investigating some different data-warehousing patterns for a project at work, it's been a fascinating look into the difference between engineering problems and running actual scientific inquiries into a problem. Engineering is so often concerned with constraints and implementation concerns because most problems have fairly well-established solutions within the computer science field. But at a certain point with engineering you run into problems that require a detailed and scientific inquiry that leads you by first principles into territory you, the engineer, were unfamiliar with.

I have to avoid speaking about specifics due to NDA concerns, but the problem involves a flattened

.bak

If any reader is familiar with massive data transfers, they'll start to piece together the solution, but if you are not familiar with data warehousing you might start out naively reading tens of millions of records from your RDS instance into a postgres instance, performing ETL while holding the RDS connection open, and finding out you've spent 40 minutes synchronously writing data from one to the other in a process that is supposed to become an hourly dump. Hahaha! By my estimates this implementation would have cost us well over a thousand dollars a month to run!

Where engineering is concerned with this is relating to the process of how to efficiently perform this operation in a fraction of this naive implementation's runtime, but it is the process of Computer Science which ultimately leads the engineer to his solution. having spent the better part of the last two days, I've managed to derive "sophisticated" Transient Storage Techniques for Data Lakes: literally just dumping the MSSQL data out to .tsv files in an s3 bucket for asynchronous writes to my application warehouse database. Sometimes you spend hours chasing parallelism, batch-write techniques, microsecond differences between INSERT and COPY, and ultimately realize the bonehead implementation is the fastest, cheapest, and most-integral!

And the Novice Data Technician (me) can really only arrive at this conclusion via research and metrics. It Is By Measurement We Live And Die!

I've always struggled with any writing endeavor of mine with being unhappy with my output and slowing down as a result. Part of it is fear of quality and applicability, but another is a fear of saying mundane things and being perceived as saying nothing really at all.

My play, here, my strategy, is to produce less imposing output through notes, and build up my concepts into a true post, where I can link errant thoughts into the blog.

A consequence of this is that I'll very quickly build a huge back-catalog of these notes, which I'll need to be able to search through efficiently. The Big Idea here is to use language models to organize these thoughts into conceptual/semantic link-throughs, which will hopefully be better than flat search and my memory haha!

None of this has of yet been written either! Again: bare-bones MVP for the site!

fun little project vibed last night was a small refactor of my JavaScript into the classic HTMX/Alpine power-duo. Turned into a huge boondoggle!

A problem with my site construction is related to my instantiation order of my scripts, where my admin page for editing these posts relies on a specific ordering of the file requires. It's a fault of my original design, so I need to go back to the drawing board with my html parser for the blog markup.

Oh, right: I write these in raw HTML. Markdown is a waste of time for anything more complex than simple paragraphs. I use an autocomplete for tags that is coded in JavaScript. It's a nice UX I've found.