Peak TOPS refers to trillions of floating point operations per second - but in the case of accelerators like NVIDIA GPUs, that number is almost always in reference to an MMA operation - performing matrix multiplication and accumulating the results.

It’s also worth noting that TOPS is always in the context of a specific precision - the data type that you’re operating on. Many vendors now report peak TOPS in a smaller data type used in quantized data formats such as FP8, INT8, or as low as FP4 (or per-block precision like NVFP4).

In addition, oftentimes TOPS are now reported using “sparse” TOPS - which assumes that the underlying matrix being multiplied has a pattern of zero or near-zero values that would effectively skip the multiplication entirely. It’s often ratios of 2:1 sparsity, so when we see reports of “X TOPS”, it’s X/2. So in the case of DGX, we should target roughly 500 TOPS.

Can we derive this number? For NVidia blackwell GPUs, the TOPS match this equation:

SM_COUNT * TENSOR_CORES_PER_SM * TENSOR_CORE_FLOPS_PER_CYCLE * CLOCK_SPEED

Substituting the Blackwell architecture parameters for the GB10 GPU:

• SMs = 48
• Tensor Cores per SM = 4
• Tensor Core FP4 FLOPS per cycle = 2048
• Clock Speed = 2.418 GHz

Substituting these values into the equation above:

Peak FP4 = 48 SMs * 4 Tensor Cores/SM * 2048 FLOPs/Core/Clock * 2.418 * 10^9 Hz Peak FP4 = 950,273,280,000 operations per second ~= 950.27 TFLOPS

But of course those are reported as sparse TOPS, so we halve the value:

Sparse FP4 = Peak FP4 / 2 Sparse FP4 = 475,136,640,000 operations per second ~= 475.14 TFLOPS

To achieve this, however, you need to make sure you’re maximizing the number of values you can fit in the registers of the tensor core as well. Specifically, you have to use the mma.sync.aligned.kind::mxf4nvf4.block_scale.scale_vec matrix multiply instruction, ensuring that you don’t pad additional bits in the register, using only the required 4 bits per element. Otherwise, for example with 8 bit padding, you’re effectively halving the utilization of the tensor core.

However, if you get all of those right, you can finally achieve max TOPS!

Thanks to Alfonso De Gregorio for the nvfp4bench tool (https://github.com/secYOUre/nvfp4bench), and for sharing the final insight of the register padding slowing things down in my own benchmarks: https://github.com/toumorokoshi/yft-ml-sandbox/blob/main/cuda/gemm/experiment.md

Additional Notes

How to Query Hardware Parameters

Method 1: Programmatically Querying SM Count and Clock Speed via CUDA API

You can write a simple CUDA program querying the cudaGetDeviceProperties API to retrieve these hardware specifications directly:

#include <stdio.h>
#include <cuda_runtime.h>

int main() {
    cudaDeviceProp prop;
    int deviceId = 0; // Target GPU device ID

    if (cudaGetDeviceProperties(&prop, deviceId) == cudaSuccess) {
        printf("GPU Device: %s\n", prop.name);
        printf("SM Count (multiProcessorCount): %d\n", prop.multiProcessorCount);

        int clockRateKHz = 0;
        // Query clock rate attribute (cudaDevAttrClockRate)
        if (cudaDeviceGetAttribute(&clockRateKHz, cudaDevAttrClockRate, deviceId) == cudaSuccess) {
            printf("Clock Rate (cudaDevAttrClockRate): %d kHz (%.3f GHz)\n", clockRateKHz, clockRateKHz / 1e6);
        }
    }
    return 0;
}

Inspecting Compute Capability via nvidia-smi

You can query the GPU model name and its CUDA Compute Capability from the command line:

nvidia-smi --query-gpu=name,compute_cap --format=csv

For example, this returns NVIDIA GB10, 12.1. Once you have the Compute Capability, you can reference the NVIDIA Developer CUDA GPUs Page and the NVIDIA CUDA C++ Programming Guide Architecture Specs to look up the exact SM counts and Tensor Core properties.

References

• Information about SM / Tensor Core counts: https://chipsandcheese.com/p/analyzing-nvidia-gb10s-gpu
• NVIDIA Blackwell Architecture Whitepaper: NVIDIA Blackwell GPU Architecture Whitepaper - Core specifications for SM counts, fifth-generation Tensor Cores, and FP4 throughput metrics.

That all said, it’s a matter of time.

How do you run local LLMs?

llama.cpp has been a good harness:

• It’s able to run most of the modern models without issue.
• It has a simple command, llama-server, for serving the model text-completion API interface that is commonly used by harnesses.

Using it is as simple as downloading the prebuilt binaries from the GitHub. More ideally you build from source, which can sometimes improve support for your GPU as the build can detect it and compile itself appropriately.

llama.cpp works with models that are saved in the gguf format. I’ve found that unsloth.ai’s huggingface collections have most models I’ve wanted to try.

I grab a model and serve it from my NVidia Spark DGX at port 0.0.0.0 so my other machines can access it:

llama-server -hf unsloth/gemma-4-E4B-it-GGUF:UD-Q4_K_XL -h 0.0.0.0

What impacts the runtime latency of a model

A critical aspect of local models is the runtime latency - I think roughly 60 tokens / second is the sweet spot, producing a good amount of code quickly without having to shift my focus for long periods of time.

It’s a bit reductionist to boil things down to a few specific parameters, but with the model’s I’ve been testing I think the general factors I see are:

• Total size of the weights: a combination of total parameter count * data format (fp16, fp8, int8, and lower). Running models with larger weights is bottle-necked by the total amount of dram that your GPU supports (i.e. the DGX spark has 128GB of unified memory available).
• The size of the effective weights: using techniques like mixture of experts, not all weights are utilized on each inference run. Although the weights still need to be loaded into dram to ensure they can be quickly read for each token prediction. This is limited by memory bandwidth to load the values by GPU, or in rarer cases the tops.

What models work well?

Qwen3.6-27b

I’ve heard this is a great model, but the 7-8 token/s were not enough for me to be truly productive: especially with the amount of thinking it does, it barely gets to a tool call within the span of 10 minutes. Even with multi-token-prediction (MTP) where a speedup is expected, it is just too slow.

Qwen3-code-next

I’ve found that this has been fairly productive - at 60+ tok/s it’s able to produce code efficiently, and call tools appropriately. I’ve had it write a couple changes to vs code extensions, or add features to fairly large frontend applications.

It is definitely not as robust as my go-tos: Cursor’s default and Gemini flash 3.5 medium: both can make these changes and test them without issue.

Where do local models fall short?

Despite my enthusiasm, local models are still no where near good enough to replace all use cases I have for larger models. Examples include:

• Getting stuck into loops: even on relatively simple solutions (remove all translucent panels in this react page), it will get stuck in a loop where it redoes and undoes the change, because it keeps second-guessing itself.
• Requiring very specific instructions: with models like Gemini-3.5-medium I can just say “add a copy to jira link on the issue page”. With Qwen3-coder-next I have to give a precise list of steps, sometimes mentioning what files to touch.
• With all the local models I’ve tried, I’ve had to give specific feedback after the change as well - in some cases the feature is entirely incorrect (e.g. access to the Jira API doesn’t work).

But in some cases it’s able to read the codebase, produce fixes, and resolve them without personal intervention. I couldn’t imagine a local model that I can run on a tiny computer on my desk being capable of that a year ago.

Conclusion

Although local LLMs aren’t all I need yet, it’s very easy to see a future where that may be the case. It’s going to be a combination of:

• Better models that need fewer weights to achieve similar benchmarks.
• Increased memory storage to enable models with a larger number of total parameters.
• Increased memory bandwidth and/or flops to enable running models at much faster tokens / second for larger effective weights.

Side quest: Profiling my GPU

I really wanted to get Qwen 3.6 working, so I tried to profile the execution of the model. To do so on an NVidia GPU, one can use Nvidia Nsight Systems to get a sense of the kernels that have the longest runtime:

nsys -o llama_profile ./build/bin/llama-cli -hf ${MODEL} -p "The quick brown fox" -n 5 --no-conversation

Then produce a match that looks at the specific kernels in question:

sudo -E /usr/local/cuda/bin/ncu -f -k regex:'(quantize_q8_1|mul_mat_vec_q|k_bin_bcast|k_get_rows_float)' -o $PWD/llama_profile_report ~/bin/llama-completion -hf ${MODEL} -p "The quick brown fox" -n 1 -no-cnv

What’s interesting about this investigation is that I found that the workload is neither saturating compute nor memory bandwidth - the SM activation actually seems to be somewhat uneven, perhaps due to sparse matrix multiplication. Something I plan on looking at, with a write up in the future.

References

The primary problem has to do with AEP-compliant APIs that have a subpath prefix. An example is something like:

api.example.com/users/v1

Here the resource path starts after a constant prefix in the API.

The question is: should APIs with a path prefix like this be allowed? and if so, how should the clients and consumers handle this?

Should APIs with path prefixes be allowed?

Even today, having a path prefix is a very common attribute in APIs. Therefore, I don’t see much of an option here but to allow these.

Examples include:

• The Google APIs, which are always wrapped with a version prefix.
• The Roblox Cloud APIs, prefixed with a version and cloud prefix.

To exclude these APIs from compliance because their existence of a prefix would significantly hamper the adoption of the AEPs.

Therefore, I think the choice to include support for this is more of a practical choice than one taken for an ideal design.

Problems with a path prefix

Introducing this pattern, however, comes with challenges. Enumerating the difficulties, those are:

A path prefix breaks the collection/resource pattern

The main issue with a prefix comes with the ability to semantically interpret the meaning of a path. The resource model in the AEP specific includes a pattern of collection, resource id elements. For example, take a book in a bookshelf:

/bookshelves/living-room/books/pride-and-prejudice.

From here, it’s very easy to understand the following:

• there are two collections of resources: bookshelves and books.
• books are a subcollection under a bookshelf.
• The bookshelf in question is living-room, while the book in question is pride-and-prejudice.

If we add a prefix, say, cloud/v1:

/cloud/v1/bookshelves/living-room/books/pride-and-prejudice

Now there is some ambiguity: is v1 a cloud? Although this is immediately obvious to a human, to a machine there is no longer a discrete algorithm to extract collections and elements.

Addressing the problems

Although the above brings up more abstract problems, we need to look at how to resolve them discretely. Thinking through where there are practical challenges:

How to reference a resource

For a resource reference, the path to the resource is used. Should this resource include the path prefix, or no?

    # with the prefix
    book: "/cloud/v1/bookshelves/living-room/books/pride-and-prejudice",
    # without
    book: "bookshelves/living-room/books/pride-and-prejudice",

For protobuf APIs in the AEPs, the path of the resource is used directly in operations such as Get / Update / Delete. Therefore, it does not need the prefix.

For REST JSON APIs, the reference will probably, at some point, be used to reconstruct the full path. For example, a backend may perform a GET on the HTTP path of the resource to retrieve information about it. However, resolving that resource reference would require some knowledge of the API domain to begin with, so it wouldn’t be a stretch to also intern the path.

The biggest issue is with full resource paths - examples where a resource references another resource in a different API. However, that too could also be solved by including the full path, including the api name, which in turn would also include the path prefix:

{api name}/{resource path}
{api.example.com/cloud/v1}/{bookshelves/living-room/books/pride-and-prejudice}

So there are cases well handled as well.

Conclusion

To support subpaths in API, I propose the following:

1. full resource paths to other APIs always include the api name: this enables clients to retrieve the resource without knowledge of where the API description of that separate API exists.
   1. alternatively, the API could describe the API name it expects via an annotation. This would allow a client to resolve that path.
2. modify the API names description to clarify that it can include a sub-path.
   1. this also solves a separate problem, where an API may have resources tightly coupled to a separate path.

I could imagine there’s some differences:

• If a field is missing, an apply could reject the request, while update with allow_missing would silently accept it with some default.

Today, apply with fields missing does not actually state that the request should be rejected. Instead, it states:

Note that PUT requests with fields missing in the resource may result in overwriting values in the resource with existing values. For that reason, AEP-compliant APIs generally use the PATCH HTTP verb.

So the behavior is actually one of:

• use the default values for those fields.
• do not modify the existing one.

But does not clarify which is expected. This should be fixed regardless.

If the choice is to leave unset values unmodified, that it is identical to the behavior of update with allow_missing.

If default values are chosen, then in proto, that would be nearly identical to an update with a full field mask set (a wildcard *).

But thinking a bit about that second user journey, generally the idea that one would like to reset a resource back to it’s default values is somewhat non-sensical:

• If one would like to update a resource back to it’s default, set it explicitly in your update.
• If you would like to leave the value alone, leave it unset.

This is a relatively easy thing to accomplish in OAS: one can examine the fields in a resource, see if they are unset, and then in turn only modify the ones that are set.

For protobuf, this is a bit more difficult because of the fact that non-optional fields are set to their default values. However, even there I think there’s a solution: effectively make every protobuf field explicitly optional, at which point it behaves just like json.

In the above case, one can just set the fields they would like to modify, or are aware of. Combined with a field mask, this would determine wet

User journeys

Conclusions

Ultimately, allow_missing and update, due to it’s inclusion of field masks, are a more flexible version of the apply method. Generally clients should just use that method across the board.

In addition, the following guidance should probably be added:

• update protobuf guidance that all fields should be optional.
• the apply field should clarify whether it will use default values if a field is missing, or leave the field unmodified.
• the apply field should clarify that a request with required fields missing will reject the response.

The background

As of 2025-09-13, the aeps have a pattern in which one can “soft delete” a resource - where it not actually removed from a collection, but is actually flagged as deleted. This allows the resource to be recoverable later.

The soft delete pattern, I believe, exists to serve the purpose of situations where recovery is desired, such as most situations where persistent data is stored:

• A database, where recreating the resource does not restore any valuble data stored.
• A filesystem, where a file may need to be recovered after the fact.

The implementation of soft delete today

The current implementation of AEPs’ soft delete boils down to the following:

1. a new custom method, undelete, on the resource.
2. an added field show_deleted to the List standard method, where resources are hidden unless specified.
3. an added field show_deleted to the Get standard method, where the resource will return 410 without it.

There are a few other details (such as the usage of expiry_date) that are additional, but do not force any additional fields on the standard methods.

The problems: soft delete is not compatible with declarative clients

Declarative clients expect consistent resource-oriented operations on each resource - for simple CRUD on a resource, declarative clients are able to easily map each operation to the resource lifecycle.

graph LR
  exists
  not_exists
  exists -- "update" --> exists
  not_exists -- "create" --> exists
  exists -- "delete" --> not_exists

For soft delete, where would that fit in? Effectively it creates another state - soft deleted.

graph LR
  exists
  soft_deleted
  not_exists
  not_exists -- "create" --> exists
  exists -- "update" --> exists
  soft_delete -- "undelete" --> exists
  soft_delete -- "expiry hit" --> not_exists

But this may also result in weird cases like:

A resource “create” throwing an error because the resource is soft-deleted, and therefore exists. But a get would return a 404.

Proposed alternative

Since the primary use case is about backing up and enabling restoration of data, the proposal would be to replace these augmentations on the primary resource, to adding a second resource for “backups” or “snapshots”.

The pattern would look something like:

/database/foo
/database-snapshots/foo/snapshots/latest

The database-snapshot could be support a custom method, restore, that would be similar to undelete and bring an old resource back.

This would be similar to the resource revision pattern - where a design pattern is introduced by adding a new resource, not by augmenting standard methods.

The agentic workflow is something I’m calling “local, parallel, and autonomous”. It’s a dive deep into making a whole codebase from scratch, completely hands-off.

The Core Attributes

The main pillars for this workflow are straightforward:

• Local: All the git worktrees run locally on my machine, avoiding the complications of remote execution.
• Parallel: It’s built to scale so multiple agents can work on different issues across multiple worktrees at the same time.
• Autonomous: The agents complete issues from start to finish without human intervention.

Choosing the Right Projects

Let’s be clear: as of March 2026, there are a lot of risks with this approach. I wouldn’t confidently build and deploy a production SaaS web application this way because the necessary guardrails for safety and privacy requirements just aren’t there yet.

Because of that, I choose self-contained, smaller projects. I’ve built a few codebases this way, including:

• Small VS Code extensions (one to synchronize my dotfiles, another to add missing file operations).
• A self-contained GitHub page that converts LaTeX to Markdown and plaintext.
• Lelouch, the workload orchestrator I use for this very process.

For more complex, large-scale systems, I still rely heavily on a manual cycle where the AI generates code and I heavily review it.

Bootstrapping: Setting the Guardrails

To get things started, I wrote a repository called agentic-bootstrap to provide the scaffolding. Inside its templates/ directory, I keep generic rules that help agents stay on the rails.

The bootstrap relies on a few key components:

• AGENTS.md: This file acts as the playbook. It tells agents to study the README first, ensures CI passes, enforces linting rules, and mandates that documentation is always updated.
• specs/: This directory holds design specifications. Splitting the design up limits the context an agent has to load to accomplish a particular task, separating the “designer” agent from the “executor” agent.
• Example Files: For the Heaptrack UI, I included a sample .zst file in the repo so the agent actually knows how to read the format it’s supposed to parse.

Writing Specs: The “Grill” Approach

When it’s time to write the overall design, you can write it yourself, but I used an approach called “grilling” to illustrate another, more agentic way to bootstrap.

I tell the agent: “Interview me about the purpose of this project”. It asks me questions about architecture and UI, and I respond with my requirements—for example, that the app should be a purely client-side React app, include dark mode, and support drag-and-drop.

The agent then writes out the design documents in the specs/ directory. I usually do a quick offline review; for instance, the agent once hallucinated some weird typography requirements asking for “Apple’s clear glass” style, which I promptly deleted.

Managing the Queue with Beads

For the issue database, I use a tool called Beads, created by Steve Yegge. It acts as a local database for issues, supports being reused across multiple work trees, and is highly agent-friendly with support for --json flags.

You simply initialize it with bd init --stealth. From there, you can manage the queue:

• bd create to make new issues.
• bd update {id} --status=open or --status=closed to manage state.
• bd delete {id} to remove them.

I like to use a “thinking” model for a seeder prompt to write highly detailed initial issues, and I use the Beads VS Code extension to visually track what the agents are working on.

Orchestration with Lelouch

To orchestrate the workers, I wrote Lelouch. It’s effectively a way to run an agent, one per github worktree, pulling issues out of the Beads database.

To initialize it just run lelouch init per worktree. It monitors your repositories, pulling open tasks from the Beads database by priority and dispatching them.

I typically run Lelouch with the Gemini Flash model via CLI because it has a more forgiving usage limit. I also add a pre-prompt like “run tests, commit, and push” to make sure it follows through.

When I run lelouch run -v, the loop begins. It moves issues to “in progress” and logs the agent’s responses directly into the working notes, so I can see exactly what it’s up to. It’s incredibly satisfying to just watch the issues update in the VS Code extension while the agents hum away.

Handling Bugs and Gaps

The process isn’t perfect. During my Heaptrack build, the agent created a gaps.md file but failed to actually implement the missing features. I had to manually prompt it: “There are gaps in gaps.md that are not yet implemented. Please create BD issues for them.”.

When I tested the UI, I found that the flame graph had sizing issues and the .zst file wasn’t loading properly.

Fixing this is a matter of adding issues to the command line via bd q "fix the bug with the zst file not outputting the flame graph". Lelouch immediately picks it up in the background.

Takeaways for 2026

I’ve done this with four or five projects now, and having a central issue database with parallel worker agents is a scalable model.

I know that there’s been existing examples online of people who have done everything from write compilers over to full web browsers, and games with varying success. Despite that, I’m still skeptical and looking for ways to get it to be a consistent, high quality enough generator that it can be used for more production code. To get there, I think it’ll take more guardrails, especially security-related ones. Some projects are already using agents with a security persona to try to get there.

But all technology has to start somewhere, and this workflow serves as an interesting baseline for my process I intend to grow.

Recently I read about Steve Yegge’s post about GasTown, an ecosystem of agent orchestration to go get monster-sized projects done.

I was a bit slow on the uptake when it came to AI: a lot of code last year was hand-written when many had already started letting agents do most of it. My thought was, at the time, the models themselves were often unable to produce a working feature. Let alone produce good code.

But only a year later, with models like Claude Opus 4.6 and Gemini 3.1 pro, these agents are generating code extremely quickly. And the code is actually… decent. It’s not mind-blowing - the agent still makes multiple stylistic mistakes, despite my prompt telling it not to:

• It does not adopt functional programming methodologies, freely mixing IO with business logic.
• It repeats itself constantly.
• It often re-writes things it can use a library for.

But it’s good enough where I can get into a productive loop.

My workflow today

My workflow looks like:

1. Write up a design or prompt (I usually like to document my actual written prose somewhere, usually a DESIGN.md).
2. Ask Cursor / Claude / Gemini to implement it.
3. Review the code, ask it to fix things. Back to 1 if needed.
4. Validate the feature e2e. Back to 1 if needed.
5. Commit and push.

I’d argue this is very hands-on. But even with this level of micro-managing, I get a ton of changes done in a short period. Over 1.5 hours on a random Saturday, I got through 7 feature requests in aep-e2e-validator, and I felt good about the code and the result of those. Probably 3-4x what I could with a coding-first approach, and with probably one half of the mental load.

Oh, and I also created a code extension to fill in some missing gaps I had in openvsx (https://github.com/toumorokoshi/code-fileclrk). And a couple bugs in other repositories. So I guess that’s more like 10 contributions in a 1.5 hour period, and a 5x increase?

Regardless the multiplier at this point is astounding. As Steve said in his blog post, the bottleneck here really is no longer the code.

My workflow in the future

I thought the above was great, but then I read GasTown. To be clear, I am a still a pessimist on AI, so I don’t want to say I’ve drunk the Kool-aid just yet. But the extremely detailed post helped me really understand what an 100x future could look like. It’s basically layers of abstractions, but with AI agents filling almost every single piece of the puzzle:

• agents are writing code.
• agents are reviewing PRs.
• agents are helping summarize the changes and writing them out to a record of what decisions were made.
• you talk to an agent to help dispatch these tasks to other agents.

And so on - multiple role-based agents, that fill whatever gap you’ve encountered with the other agents you’ve already deployed. Assuming the agent is good enough, or you’ve anchored the manual review to the point of no return (e.g. before performing a financial transaction, or perhaps cutting a release), you could delegate the next level of review over and over again.

And intuitively - this kind of makes a wacky kind of sense, where you are abstracting yourself to the point where you are focusing on the problem where human judgement is truly needed. In the past, for someone to get something accomplished with software, you had to work on every single piece by hand (perhaps except the hardware you run on). But now, if there’s a task you don’t find particularly appealing, and as long as you’re willing to do some manual review, you can definitely delegate that to an agent!

The caveat: you need the domain knowledge to succeed

Some might read the above and believe that this means that an individual does not need the same skills that the agent does. For example, a non-technical person can write software. I don’t really believe that’s the case, at least not 100%.

For one, it’s important to know that there are just some concerns that are so mission-critical that you cannot reasonably accomplish that without some sort of expertise or awareness. Those are:

• Proper resource management, quotas, and monitoring so you don’t get a giant check that backrupts you.
• Security. If your service is compromised, the damage is irreperable.

But there’s a huge swath of things that you don’t really have to understand too deeply at the beginning. And as long as you have the skills and time to dive in, AI could take the first swag at it:

• command-line interfaces.
• applications that run locally.
• any codebases that have significant guardrails (linting / testing / etc).

Final Thoughts

So what is the bottleneck now?

It feels like the bottleneck now is the human’s ability to reason about a problem and figure out a good solution. I suppose one can argue that human reasoning was always the bottleneck, but I think the abstraction is at a higher level now.

Oh, and money / energy. You can produce as much as you have money to pay for an agent to generate for you. That or your human ability to think about these problems, which limits you first.

Human interaction is still needed

In this fever dream of AI, there are no humans. But to make real change happen in an organization, you still need to talk to people, and that’s the real challenge.

Pretty much everything that has real impact, to some extent, requires thoughtful interaction with others:

• Getting buy-in on the idea.
• Getting others to use it (sharing demos, recordings, talking to people in 1-1s and through slack).
• Getting approvals to merge or ship the code.
• Getting the team that owns the product to accept your idea and put it on their roadmap (or accept your code).

So although some coding is trivial now, I don’t believe that the bulk of the my work, for example, is removed. Communication and interaction with individuals is still key.

Agents give us the freedom to dive into the problem we want to

Perhaps there is a world where someone chooses to completely ignore code or a particular engineering problem algother. But I don’t really see this as my motivation.

I think agents provide us the freedom to work on the problems we want to, or perhaps minimize the time we spend on the problems we don’t want to work on. We have a fairly autonomous coder / problem solver than can get things mostly right, and we can trust if we need to.

But if we want to, we can dive right in! And there’s reasons to do so: the code may have gotten too messy, the abstractions are not easily understood, or the code is not performant.

And if you want to assert that level of control and code something yourself, you can! So again, in some ways it’s refreshing in that you can spend more of your time on the problems you care about, not just the rote ones that need to be done.

When and how will we get to this glorious future?

So when can we get to this world where agents completely autonomously write their own code and produce real, working products?

I think for some software engineers, they’re basically there today. GasTown seems like it’s run fairly automated with agents working on it all the time. I don’t think throwing agents at compilers and browsers has produced a working product either.

For me personally, I don’t know if I have a project that really is accelerated by 100 autonomous agents all writing code. But I’d like to start climbing this maturity ladder to see if I can squeeze out a little bit more of that time to think about the problems I’m really interested in diving into.

Summary

This post outlines an experiment I ran to try to better understand the unique data inputs I’m using for model training. This is a modification of DVGS - “Data Valuation via Gradient Similarity”, that I’m calling DUGS (data uniquess via gradient simlarity).

Algorithm high level

The high level idea is:

1. Grab the following: a. An already trained model b. A random sampling of the data you would like to evalute of size X
2. Initialize a map of {data_point_id, uniquess_dimension} to store differing data points.
3. Run a training pass on each datapoint. Calculate the gradient up to a layer Z.
4. Reduce the dimensionality of that vector via a random matrix {gradient_size, uniqueness_dimension} to reduce the cost of calculating gradient similarity. (Johnson-Lindenstrauss projections)
5. Use cosine similarity to compare it to existing vectors in the list
   1. if the similarity is less than some threshold (0.3 by default) from any of the previous data points, add the new data point to the list.

Tunable parameters

Data Set Size

The size of the data set you are running the evaluation on will affect the runtime of the algorithm linearly.

Uniqueness dimension via Johnson-lindestrauss lemma error

The smaller the dimension size you can reduce to, the more efficient the calculation is.

The Johnson-Lindenstrauss Lemma states that preserving the vector dimensionality within an error bound e for a dataset size N is calculated as:

k > (8 * ln(N) / e^2)

Although we are only seeking a limited number of datasets, making this match the target full dataset size ensures that there is sufficient dimensionality to understand the nuances between the dataset. The main tunable parameter is the margin of error introduced by the reduction of matrix for comparison.

For example, for 10,000 images, and a desired error of 0.001, you would have to have a base 2 dimension of roughly 8 * ln(10000) / (0.001^2)) = 73682722, or somewhere between 2^26 ~ 2^27 (rounding to some base 2 size matrix is preferred to align with scheduling on processors which primarily have cache sizes, multithreaded processor / code SM counts that align to some multiple of 2).

Number of layers to backpropagate

This one is a model-specific choice: the more layers that backpropagation is run, the runtime complexity will multiplied by the cost to compute the backpropagation of that layer.

As a rule of thumb, I think you want to only go back to the number of a relatively low number of layers: there is an intuition that the later layers of a model are the ones more correlated to fine-tuned behavior for the specific task. This is probably the behavior that one is most interested in, such as wehn trying to find more datapoints of similar, but underrepresented data, to increase the distribution thereof.

Results

I tried this out in my sandbox against my toy model based on AlexNet, which uses the Imagenette dataset. Looking at the results visually, it looks like it was able to differentiate and find examples of each of the 10 categories:

Future Experiments to try

• focus on the gradient of a specific layer (e.g. the embeddings)
• use dimensionality reduction via Johnson-Lindenstrauss projections
• can we use some form of k means clustering to help group the data points?
  • this would be helpful to see how many “categories” of data there are.

My Framework 13 laptop has an issue where the battery drains very quickly, even when sleeping.

This seems to be a known issue with Framework laptops. Since I often just use my work computer during the weekdays, the laptop is dead before I can use it again.

Reviewing sleep states available

In Linux, there are specific levels of sleep states that can be used:

• freeze (S0ix)
• standby (S1): rarely used in modern systems.
• mem (S3): hardware is powered off except ram.
• disk (S4): hibernate. system state is moved to disk.

Checking power states available

First I checked what was available with:

cat /sys/power/state
# freeze mem

So freeze and mem are available.

Configuring hibernate with LUKS

I like to use LUKS (Linux Unified Key Setup) to encrypt my drives. To do so with hibernate, the following workflow is required:

1. use the bootloader to loader the initramfs
2. have the initramfs decrypt the LVM volume that contains the main partition as well as swap.
3. the initramfs detects that the swap partition is available and restores the system state from it, if a hibernate image is found.

Configuring the partitions

The final partition structure will look something like:

• /dev/nvme0n1p1 (EFI / bootloader)
• /dev/nvme0n1p2 Linux filesystem partition: an unencrypted boot partition that contains the OS needed to perform the decryption of the encrypted drive.
• /dev/nvme0n1p3 Linux filesystem partition: the encrypted disk partition.
  • /dev/mapper/dm-crypt-0
    • /dev/mapper/ubuntu–vg-ubuntu–lv: the actual OS.
    • /dev/mapper/swap: the swap space that the partition will hibernate to.

Steps

NOTE: these were with my install of ubuntu 25.10. YMMV.

Resize the partition and make a swap partition

1. use a live USB so I can modify the partition
2. open the luks partition: sudo cryptsetup open ${partition} ${lvm-volume-name}
3. reduce the size: sudo lvreduce -r -L -128G /dev/mapper/${root-lvm-partition}
4. create the volume: sudo lvcreate -L 128G -n swap ${lvm-volume-name}
5. format as swap: sudo mkswap /dev/mapper/${swap-lvm-partition}

Make the partition swap

This ensures the swap partition is available on boot to suspend to.

When back into the OS:

1. sudo swapon /dev/mapper/${swap-partition-name}
2. Update /etc/fstab to mount the swap on boot:

/dev/mapper/{swap-partition-name} none swap sw 0 0

set the swap partition as a hibernate partition

This tells the kernel where to look for the hibernate image when resuming.

1. modify GRUB_CMDLINE_LINUX_DEFAULT in /etc/grub/config with:

resume=/dev/mapper/{swap-partition-name}

1. run sudo update-grub

enable hibernate in the linux kernel image

This is required for the initramfs to know how to restore from the hibernate image.

1. create file /etc/initramfs-tools/conf.d/resume with:

RESUME=/dev/mapper/{swap-partition-name}

1. run sudo update-initramfs -u -k all

disable secure boot

The last step is to disable secure boot in the BIOS.

Theoretically there is a way to sign the hibernated image with a TPM (trusted partner module) or a MOK (machine-only-key), but I didn’t want to have to re-encrypt my volume.

Conclusion

Success! After the above, I can now hibernate my laptop.

Even with my 64GB of RAM, the hibernate / restore has been pretty quick so far: roughly 20 seconds at most to come back up from a full hibernate. Good solution for laptops I use once in 24 hours.

see /diet/2022 for an older version of this article.

Short checklist

• Vegan diet
• Drink caffeinated drinks (e.g. coffee) to suppress appetite, and to help combat memory loss.
• Sodas are a great way to suppress appetite.
• Target 1.6g protein / kg body weight day.
• Target 45g fiber / day.
• Try to get as close to zero for saturated fat intake.
• Target 1400kcal for cutting, 1800kcal for bulking.
  • when bulking, do a slow bulk to build muscle.
• targetting low carb diet (50 carbs / day).
• Moderate sodium intake
• Try to hit 100% RDA on potassium (this is very, very hard): this helps counteract bloating caused by sodium.

Example diets

Major Ideas

Mostly vegan (plant-based diet)

People who eat a plant-based diet live 7 years longer.

It’s hard for me to go completely vegan (I like my seafood and dairy), so I try to go for vegan meals most of the week at home. When I eat out I eat vegetarian or seafood.

From what I read in Blue Zones (above), eating meat once a week still helps you get a lot of the longevity benefits.

Those who have plant-based high protein diets also tend to have better kidney health than those who dairy / meat based high protein diets.

High-protein

I eat 1.6 grams of protein per 1KG of body weight a day at minimum. Studies have shown that this is the amount that has shown to maximize muscular hypertrophy. I strive to maximize muscle mass ultimately for increasing my healthspan.

With a vegan diet, that number likely should be higher: vegan proteins are not always complete, and may not be in an easily digestable form unlike meat.

However, I do strive for foods that have a diaas score close to 1 or greater:

• soy protein isolate, soybeans, soymilk, tofu.
• pea protein.
• beans (kidney, fava).

Targetting Caloric Restriction

I’m currently in the middle of trying to lose weight: my last Dexa scan in 2022/10 put me at 21% body fat, which is much higher than I’m hoping. My current target is 15% body fat, which means I have to lose 12 lbs of body weight.

To that end, I’m looking at some minor caloric restriction: at 1700 kcal / day, and assuming I can build up a daily caloric expendature of 2100 kcal, that would be me at 3500 / (2100 - 1700) ~ 8.75 days to lose a pound of weight. And ideally I could my weight in 108 days (~4 months).

I’m mixing that with lifting weights to try to guarantee muscle hypertrophy.

In reality my caloric intake is often higher due to limited self-control, but I’m working on that.

Other Tips

Sucralose may cause NAFLD

When I started eating four servings of Huel protein powder a day (to try to up my protein intake, those 80 grams help) along with drinking a sugar-free sweet coffee daily, I found that my ALT and AST numbers have grown significantly (11->16 and 17->25, respectively over 10 months).

I’m not sure the precise cause, by after doing some research I found some research in mice that shows sucralose and stevia (and regular sugar) consumption increasing ALT and AST.

Correlation is not causation, but I’m currently (2023/04) trying to lower my Sucralose consumption significantly to see if my numbers change at all.

Only Allulose and Stevia for non-nutritive sweeteners

Several non-nutritive sweeteners have downsides:

• Aspartame may cause an insulin response.
• Erithrytol may cause blood clotting, and impact the blood/brain barrier.
• Sucralose may cause NAFLD.

Which leaves a limited set of non-nutritive sweeteners to choose from:

• Allulose
• Stevia

Specific Food Recommendations

To hit a 50 carb target with 1400 kcal, you need to target foods that provide roughly 1 carb per 26 kcal or less.

Also, unlike most low carb diets, I prefer to stay low in saturated fat as well. It’s a hard balance but I try to make sure these foods have relatively low saturated fat.

For my specific dietary preferences, my recommendations are:

Nespresso

I like to drink Nespresso every morning. I generally may make a mezzo (half americano, half soy latte) with the following:

• Mezzo with Tropical Coconut Flavor + 180ml soy milk.
• Straight: Peppermint Pinwheel.
• Bianco Doppio with 120ml milk.
• 2x Altissio with 180ml milk (I like this because they offer a decaf option).

Sometimes I replace the soy with a larger volume of macadamia milk (fewer calories).

Good Foods

• Pistachio: relatively lower carbs, low saturated fat, high potassium.

  • high phosphorous so try to eat it in moderation.