I’ve been using the workstack concept for years to track what I’m working on and where I got interrupted. task-stack is the natural evolution: a small system tray app that keeps a persistent, reorderable stack of tasks always one hotkey away.

The top of the stack is your current task. Everything below the top entry is queued. Press Ctrl+Shift+T from anywhere and a compact window appears where you can add, reorder, promote, and remove tasks. Close the window and the app is out of your way. The tray icon always shows the current task as its tooltip.

Why a stack, not a list

#

Todo lists are flat. Kanban boards are heavy. When you’re deep in flow and get interrupted, you don’t want to prioritize a backlog: you want to push something on top of what you’re doing and pop it off when you’re done.

A stack models interruptions naturally:

• Push: a new urgent task goes on top and becomes the current task.
• Pop: mark the task done and the next task surfaces automatically.
• Reorder: something can wait? move the task down. Something urgent? promote the task to the top.

No projects, no tags, no due dates. Just a stack of things to do, in order.

Features

#

• System tray icon with the current task as tooltip and a “Mark Done (pop)” action.
• Global hotkey (default: Ctrl+Shift+T, configurable) to bring the stack window forward from any application.
• Keyboard-driven editing: add tasks with Enter, reorder with arrow keys, promote with /, remove with Backspace. Full shortcut table in the README.
• Persistent state in ~/.task-stack.yaml. Easy to inspect, back up, or version control.
• Soft deletes: removed tasks stay in the YAML file with a deleted_at timestamp, so you keep a full history.
• Timestamps: each task tracks created_at, started_at (first time the task became current), and last_current.
• Cross-platform: works on macOS, Linux, and Windows.

Quick start

#

git clone https://github.com/TomzxCode/task-stack.git
cd task-stack/python
uv sync
uv run task-stack

The app starts in the system tray. Press the hotkey or pick “Open Stack” from the tray menu.

Data format

#

Tasks are stored in ~/.task-stack.yaml as a simple YAML list:

- text: Write blog post about task-stack
  created_at: '2026-05-02T10:00:00+00:00'
  started_at: '2026-05-02T10:00:00+00:00'
  last_current: '2026-05-02T10:30:00+00:00'
- text: Review pull requests
  created_at: '2026-05-02T09:00:00+00:00'
  deleted_at: '2026-05-02T09:45:00+00:00'

Active tasks come first in stack order. Soft-deleted tasks are appended at the end with a deleted_at timestamp. Settings (window geometry, hotkey) live in ~/.task-stack.settings.yaml.

Configure the hotkey

#

Edit ~/.task-stack.settings.yaml:

hotkey: ctrl+shift+t
# hotkey: alt+space
# hotkey: cmd+shift+space

Restart the app to apply the new hotkey. The current hotkey is shown in the tray menu.

When task-stack is useful

#

• Developers context-switching between code reviews, bug fixes, and feature work. Push the interruption on the stack, pop the interruption when done, resume what you were doing.
• Anyone who works with interruptions and wants a lightweight way to track pending work without opening a full project management tool.
• Time tracking enthusiasts who want started_at / last_current timestamps to reconstruct what they worked on during the day.

See also

#

• Workstack - the original note-taking concept that inspired task-stack.

Note (2026-07-02): gh-cached has been merged into ghx.

I use the GitHub CLI (gh) heavily, and I kept hitting the API rate limit. The pain is worst when I’m triaging issues across multiple repos or reviewing a backlog of PRs. Every gh issue list, every gh pr view, every comment fetch costs API calls I don’t need to spend.

I built gh-cached to solve the rate limit problem. gh-cached is a standalone Go binary that wraps the GitHub GraphQL API and caches every response to disk, so subsequent commands read from the local cache instead of hitting GitHub again.

The problem

#

The official gh CLI is excellent, but it’s designed for live, one-off interactions. There’s no built-in caching layer. Running gh issue list twice in five minutes makes two API calls. Browsing hundreds of issues with their comments in a large repository burns through the rate limit fast.

The problem gets worse when AI coding assistants query GitHub on my behalf. Multiple agents, multiple tools, all hitting the same API. The rate limit becomes a real bottleneck.

How gh-cached works

#

go install github.com/tomzxcode/gh-cached@latest

The cache lives at ~/.cache/gh-cached/<host>/<owner>/<repo>. Each issue and PR is stored as its own JSON file, including all comments.

Pre-populate the cache:

gh-cached cache                          # current repo
gh-cached cache --repo cli/cli           # any repo
gh-cached cache --cache-duration 120     # fresh for 2 hours

Browse issues and PRs from cache:

gh-cached issue list                     # open issues
gh-cached issue list --state all         # everything
gh-cached issue list --label bug         # filter by label
gh-cached issue list --author alice      # filter by author
gh-cached issue view 42 --comments       # view with comments

gh-cached pr list --state merged         # merged PRs
gh-cached pr list --draft                # draft PRs only
gh-cached pr view 10 --comments          # view with comments

When the cache is fresh, all filtering happens in-memory with zero API calls. When the cache is stale, gh-cached falls back to the GitHub API and updates the cache.

Why a separate tool instead of a gh extension?

#

Two reasons.

First, gh-cached uses GraphQL under the hood, which lets the tool fetch issues and PRs with their comments in fewer round trips than the REST API the official CLI defaults to. The cache-then-filter pattern also means one pre-fetch can be sliced many ways without going back to GitHub.

Second, independence. gh-cached works with just a GH_TOKEN environment variable, or falls back to gh auth token if the GitHub CLI is already installed. No plugin registration, no extension marketplace, just a binary to drop in your PATH.

The caching strategy

#

The tool uses different strategies depending on the command:

• cache fetches everything (all states, with comments) and writes one JSON file per item. Skips items already cached within the --cache-duration window (default: 60 minutes).
• issue list / pr list reads cached files and filter in-memory when fresh. Falls back to the API with server-side filters when stale.
• issue view / pr view serves from the individual cached file if less than 60 minutes old. Otherwise fetches from the API and updates the cache.

A single gh-cached cache run gives fast, offline-capable access to all issues and PRs for the next hour.

Authentication

#

Set the token in the environment:

export GH_TOKEN=ghp_...
or
export GITHUB_TOKEN=ghp_...

Or just have gh installed and authenticated: gh-cached will use gh auth token as a fallback.

When gh-cached is useful

#

• AI coding assistants that query GitHub repeatedly. Pre-populate the cache once and let tools read from disk instead of making redundant API calls.
• Repository triage where hundreds of issues need scanning with different filters. One cache fetch, then instant in-memory filtering.
• Working with multiple repositories where context switches are frequent. Cache each repo once and browse offline.
• Rate-limited environments like CI pipelines or shared machines where every API call counts.

What to Do Next

#

go install github.com/tomzxcode/gh-cached@latest
# or download a binary from https://github.com/TomzxCode/gh-cached/releases/tag/latest
gh-cached cache --repo your-org/your-repo
gh-cached issue list --state all
gh-cached pr list --state all

Software-as-a-Service gave us recurring revenue. Platform-as-a-Service gave us managed infrastructure. The next abstraction is obvious in hindsight: Profit-as-a-Service.

The Pattern

#

Every major shift in the software industry has been about abstracting away complexity.

On-premise servers became cloud infrastructure. Custom software became SaaS subscriptions. Manual operations became automation.

Each layer removes something the customer previously had to manage themselves. Each layer turns a cost center into a service. Each layer makes the underlying complexity someone else’s problem.

Profit-as-a-Service is the logical conclusion of this trend. Instead of selling software that helps you make money, you sell the money-making itself.

What It Looks Like

#

A traditional SaaS company sells you a tool. You still need to figure out how to use it to generate revenue.

A Profit-as-a-Service company sells you an outcome. The tool is invisible. The process is invisible. You pay for the result.

Examples already exist:

• Algorithmic trading platforms that let you deploy capital and collect returns without understanding the underlying strategies.
• AI-powered dropshipping services that handle product selection, listing, pricing, and fulfillment while you provide the capital.
• Automated content farms that generate SEO-optimized articles, monetize them with ads, and split the revenue with you.
• AI sales agents that prospect, qualify, and close deals on your behalf, charging only a commission on closed revenue.
• Robo-advisors that manage investment portfolios algorithmically, charging a fraction of traditional advisory fees.

In each case, the customer provides capital or data. The service provides everything else. Revenue is shared, not subscribed to.

Why Now

#

Three forces are converging to make Profit-as-a-Service viable at scale.

1. AI can now execute complex business processes autonomously

#

Large language models can write marketing copy, analyze markets, negotiate with customers, and generate code. Multi-agent systems can coordinate these capabilities into end-to-end business workflows. What previously required a team of specialists can now be done by a single API call chain.

2. Infrastructure is fully commoditized

#

Starting a business used to require incorporating, hiring, building software, and navigating regulations. Now you can spin up a fully operational e-commerce store in an afternoon using off-the-shelf tools. The barrier to entry for almost every digital business has collapsed to near zero.

3. Distribution is algorithmic

#

Social media algorithms, search engines, and ad platforms have made customer acquisition a math problem. If you can compute the expected value of an impression, you can acquire customers profitably at scale. AI is better at computing expected value than humans.

The Economics

#

The unit economics of Profit-as-a-Service are deceptively simple.

The service provider operates a system that generates revenue. The customer provides the input: capital, data, or access to a market. Revenue is split between the provider and the customer.

For the customer, the arrangement is attractive because:

• No upfront investment in tools or expertise.
• Risk is aligned (the provider only makes money if you make money).
• Scalability is built in (the system can run 24/7 without human intervention).

For the provider, the arrangement is attractive because:

• Revenue scales with customer success (no ceiling from fixed subscriptions).
• Customer acquisition is easier (pay-for-performance is an easy sell).
• Margins improve with scale (the same system serves many customers).

The critical metric is the spread between what the system generates and what it costs to operate. If a system generates $10,000/month per customer and costs $2,000/month to run, the provider can keep $4,000 and give the customer $4,000. Both parties are happy. The system scales linearly in cost but exponentially in value.

The Risks

#

Profit-as-a-Service is not without significant risks.

Alignment risk

#

When you outsource profit generation, you also outsource decision-making. The provider’s optimization target may diverge from yours, a textbook principal-agent problem. A trading algorithm might maximize short-term returns at the cost of long-term stability. A content farm might optimize for clicks at the cost of your brand reputation.

Concentration risk

#

If the service provider goes down, your revenue goes to zero. There is no fallback when the entire business process is a black box. Diversification across multiple providers becomes essential but difficult.

Regulatory risk

#

Financial services are heavily regulated. When you abstract away the details of money-making, you may also abstract away compliance. The line between “software service” and “financial service” is thin and getting thinner.

Race to the bottom

#

When the barrier to entry is low, competition drives margins toward zero. The first provider to offer automated dropshipping captures most of the value. The hundredth provider competes on price until nobody makes money.

Dependency trap

#

Once a business relies on Profit-as-a-Service, transitioning away is extremely difficult. The provider owns the process, the data, and the relationships. Switching costs are not just technical but operational and strategic.

The Spectrum

#

Profit-as-a-Service is not binary. It exists on a spectrum of how much of the profit-generating process is abstracted away.

Level 0: You do everything. You buy tools and operate them yourself. Traditional software.

Level 1: AI assists you. You use AI tools to accelerate specific tasks. Copilots and assistants.

Level 2: AI operates under your supervision. You define strategy, AI executes tactics. Current state of most AI-powered businesses.

Level 3: AI runs the process, you provide direction. You set constraints, AI handles the rest. Emerging today.

Level 4: AI runs everything, you provide capital. You fund the operation, AI decides how to deploy it. Algorithmic trading, robo-advisors.

Level 5: AI runs everything, including capital allocation. Fully autonomous business entities. Not yet real, but the trajectory is clear.

Most businesses today operate at Level 0 or 1. The opportunity is in moving up the spectrum.

Who Wins

#

The winners in the Profit-as-a-Service economy will be:

Platform providers who own the infrastructure that makes Profit-as-a-Service possible. If you operate the AI system that generates profit for thousands of businesses, you capture a slice of every dollar earned.

Capital providers who can efficiently allocate resources across multiple Profit-as-a-Service offerings. When starting a business requires no expertise, access to capital becomes the primary competitive advantage.

Specialists who can handle the edge cases that AI cannot. Regulatory compliance, strategic partnerships, and brand building remain human-dominated activities.

Arbitrageurs who identify Profit-as-a-Service opportunities before they become commoditized. The window between “novel” and “saturated” is shrinking, but the rewards for being early are enormous.

Who Loses

#

The losers will be:

Middlemen whose value proposition was information asymmetry. When AI can access and process all available information, intermediaries add no value.

Consultants who sold expertise that can now be codified. If your consulting practice can be reduced to a prompt, it will be.

SaaS companies that failed to move up the value chain. A CRM that helps you track sales will lose to an AI that makes sales for you.

Employees whose jobs consisted of executing repeatable business processes. This is the uncomfortable truth that applies across industries.

The Question

#

Profit-as-a-Service is not a prediction. It is a description of what is already happening.

The question for any business is not whether this trend will affect you. The question is whether you will be the provider or the customer.

If your business processes can be automated by AI, they will be. If you are the one automating them, you are the Profit-as-a-Service provider. If you are the one whose processes are being automated, you are about to become a customer.

Choose wisely.

The traditional code review is dying. Not because it is unnecessary, but because it is becoming unnecessary.

For decades, code review has been a cornerstone of software engineering. Pull requests, peer reviews, endless rounds of comments: this is how we have maintained code quality. But AI is fundamentally changing this equation. In my view, the question is not whether AI will replace human code review, but how quickly.

The Problem With Human Code Review

#

Human code review suffers from three fatal flaws:

1. It does not scale. As teams grow, review backlogs grow. Developers wait days or weeks for feedback, blocking progress.

2. It is inconsistent. Reviews vary wildly based on who is reviewing, when they are reviewing, and how much coffee they have had.

3. It is expensive. Senior engineers spend significant time reviewing code instead of building features. In high-cost engineering organizations, this adds up to millions of dollars annually.

The alternative, no reviews at all, is not viable either. Shipping unreviewed code is a recipe for security vulnerabilities, bugs, and technical debt.

The AI Solution: Software Factories

#

A new paradigm is emerging: the Software Factory. Instead of humans reviewing code, AI systems verify, test, and heal code autonomously. This is not theoretical, it is already running in production.

Consider StrongDM’s Software Factory, which launched in July 2025. A team of three people (a CTO, a senior manager, and a new hire) built a system that autonomously clones core products like Okta, Jira, and Slack. Their target: $1,000 per day per engineer in tokens. That sounds expensive until you realize what they are shipping.

How It Works

#

The Software Factory approach replaces human review with six verification layers:

1. Competitive Generation

#

Instead of one AI writing code, run three in parallel. Like a slot machine with three reels spinning, all generating different implementations. An automated evaluator selects the best output based on passing tests, minimal diffs, and fewer dependencies. The cost of running three models is trivial compared to the quality gain.

2. Iterative Refinement (Trycycle)

#

Define the problem, write a plan, ask “is it perfect?” If not, try again. Implement, then ask “is it perfect?” If not, try again. Trycycle runs this loop autonomously for hours.

3. Scenario-Based Validation

#

Treat scenarios like machine learning holdout sets. Store acceptance scenarios outside the codebase, then have an LLM judge whether the implementation satisfies them. Instead of a binary “tests pass”, you get a probabilistic satisfaction score measuring trajectory toward success.

4. Observability and Healing

#

Every interaction in the system gets logged to an execution database (CXDB). A Healer agent monitors this database, clusters similar problems, and writes prescriptions. No human bug reports. No human triage. Just autonomous detection and fixing.

5. Digital Twin Testing

#

Clone critical external dependencies: Google Sheets, Slack, Jira, authentication providers. Build replicas that AI agents cannot distinguish from production. Test in the most realistic environment possible without touching actual production systems.

6. Adversarial Verification

#

Separate the coding agent from the verification agent. Have a third agent actively try to break what was built. Enforce that verification criteria are authored before code, not after. This separation prevents the common anti-pattern of writing tests to match implementation rather than specify behavior.

The Economic Case

#

This approach is not just about quality, it is about economics.

StrongDM’s team reports seeing 21% more tasks completed and 98% more pull requests shipped. One case study: Nubank migrated an eight-year ETL monolith (six million lines, one thousand engineers) from an 18-month timeline to weeks. That is an 8-12x efficiency improvement with 20x cost savings.

The breakeven point is 50-70 pull requests per month. Above that threshold, the AI factory costs less than human review while delivering higher velocity.

The Five-Level Evolution

#

Dan Shapiro at StrongDM describes five levels of AI-assisted development:

Level 0: Manual (you write everything) Level 1: Offloading discrete tasks (ChatGPT for regex) Level 2: AI-native tools (90% of “AI” developers today) Level 3: Human-in-the-loop manager (reviewing all code) Level 4: You are now a product manager (spec, argue, craft skills, check tomorrow) Level 5: Dark Factory (black box: specs → software)

Most teams today are stuck at Level 2 or 3. The future is Levels 4 and 5, where humans specify constraints and AI handles everything else.

What This Means for Engineers

#

Your job is not to write code. Your job is not to read code. Your job is to solve quality problems so the factory can run.

This requires a philosophical shift. Instead of “how do I review this code?”, ask “why am I doing this?” If you can describe what is wrong, you can automate it. If you can describe what quality looks like, you can codify it as a verification rule.

The era of human-centric development is ending. AI compilers will transform specifications into deployed software. Teams will consist of AI business analysts, AI DevOps engineers, AI QA specialists, and AI compilers.

What to Do Next

#

This does not happen overnight. A realistic 16-week roadmap:

Weeks 1-2: Install Trycycle skill and competitive generation pattern Weeks 3-4: Build execution database and scenario framework Weeks 5-6: Implement Healer agent for autonomous fixes Weeks 7-8: Build digital twins for critical integrations Weeks 9-12: Migrate existing codebase to spec-driven workflow Weeks 13-16: Fine-tuning and compounding learning

The results compound. Weeks 1-4 might yield 5-10x velocity on simple tasks. By week 16, teams report 2x monthly speed improvements with compounding gains continuing.

Open Questions

#

This is not a solved problem. Key research questions remain:

• Is $1,000/day per engineer in tokens realistic or an outlier?
• How do patterns learned in one domain transfer to another?
• When does fine-tuning cost outweigh compounding benefits?
• What specific patterns trigger unavoidable human review?
• How do you validate security without human review of auth logic?

These are not blockers, they are opportunities for teams to pioneer solutions.

The End of an Era

#

The traditional code review served us well. But like manual testing before automated test suites, its time is passing. The future is not humans reviewing AI code. It is humans designing verification systems that make human review unnecessary.

The question is no longer whether your team will adopt this approach. The question is whether your competitors will adopt it first.

References

#

Primary Sources

StrongDM Software Factory. Production deployment of autonomous code generation systems. https://factory.strongdm.ai/

Kilroy. Open-source CLI for running StrongDM-style pipelines locally. https://github.com/danshapiro/kilroy

Attractor. Provider-agnostic framework for autonomous code generation. https://github.com/strongdm/attractor

Trycycle. Simple skill for iterative refinement loops. https://github.com/danshapiro/trycycle

Devin. AI-powered software engineering platform with fine-tuning capabilities. https://devin.ai/

Analysis and Commentary

Willison, Simon. “Software Factory.” https://simonwillison.net/2026/Feb/7/software-factory/

Shapiro, Dan. “The Five Levels.” https://www.danshapiro.com/blog/2026/01/the-five-levels/

Shapiro, Dan. “Dark Factories.” https://www.danshapiro.com/blog/2026/03/dark-factories/

Shapiro, Dan. “You Don’t Write the Code.” https://www.danshapiro.com/blog/2026/02/you-dont-write-the-code/

LukePM. “The Software Factory.” https://lukepm.com/blog/the-software-factory/

Latent Space. “Reviews Dead.” https://www.latent.space/p/reviews-dead

Case Studies

Nubank ETL Migration. Eight-year monolith migrated in weeks using Devin. https://devin.ai/

StrongDM Security Software. Autonomous cloning of Okta, Jira, and Slack. https://factory.strongdm.ai/

Prompt

#

Write an article about Darwinian software development, the use of LLM swarms to identify the best solution to a problem.

Answer

#

In the traditional world of coding, software is “built.” An architect designs a blueprint, and developers lay the bricks. But in the era of Generative AI, we are moving toward a paradigm where software is evolved.

Darwinian Software Development is an emerging methodology that uses “swarms” of Large Language Models (LLMs) to iterate, compete, and select the most efficient code through a process mirroring natural selection.

How the Swarm Works

#

Instead of asking a single AI to write a function, Darwinian development deploys a multi-agent system (a swarm) to tackle the same problem from different angles. The process generally follows four biological phases:

• Variation (The Mutation): Multiple LLM agents are given the same prompt but with different “temperaments” or system instructions. One might prioritize memory efficiency, another readability, and a third raw speed.
• Competition (The Struggle for Life): The agents generate dozens of potential solutions. The solutions aren’t just checked for syntax; they are put into a “sandbox” to run against unit tests and edge cases.
• Selection (Fitness Function): An automated “Judge” agent (or a specialized testing suite) evaluates the outputs. Only the code that passes the most tests with the lowest latency or resource consumption “survives.”
• Heredity (Refinement): The winning code is then used as the “DNA” for the next generation. The swarm takes the best-performing snippet and attempts to optimize it further until a “perfect” solution is reached.

Why Swarms Outperform Single Models

#

The “Darwinian” approach solves the two biggest headaches in AI-assisted coding: hallucinations and tunnel vision.

• Error Correction: If one agent introduces a bug, the likelihood that five other agents will make the exact same error is low. The swarm acts as a self-healing mechanism.
• Diverse Architectures: One LLM might get stuck on a specific logic path. A swarm explores the entire fitness landscape, finding creative solutions a human (or a single AI) might never consider.
• Performance Benchmarking: By racing agents against each other, the system naturally optimizes for performance.

The “Fitness Function” Problem

#

The biggest challenge in Darwinian development isn’t the AI; it’s the criteria. For natural selection to work, the environment must be rigorous. If your “fitness function” (the tests you use to judge the code) is poorly written, the AI will evolve to pass the test while still being technically broken. This failure mode is known as reward hacking. To counter reward hacking, modern swarms often include “Adversarial Agents” whose only job is to write difficult unit tests to try and “kill” the code generated by the other agents.

The Future: Software That Self-Improves

#

We are approaching a point where software won’t be static. Imagine a server that monitors its own performance and, upon detecting a bottleneck, spawns a Darwinian swarm to rewrite its own inefficient modules in real-time. In this new world, the developer’s role shifts from writer to naturalist. You aren’t typing the lines; you are defining the environment in which the best code can grow.

Imagine you can run hundreds or thousands of coding agents in parallel. How would you use them? The interesting answer is not “do everything faster”, but rather what fundamentally changes when parallelism is cheap.

From Sequential Exploration to Parallel Search

#

When you have one agent, you think carefully before acting, because going down dead ends is expensive. With thousands of agents, the calculus flips. Exploration becomes cheap, and convergence becomes the hard problem. Your job shifts from “what should I try?” to “how do I synthesize thousands of results?”

High-Leverage Use Patterns

#

Speculative execution on decisions. At every architectural fork, such as “should this be a queue-based system or polling?”, you do not decide, you branch. Two fleets of agents build both options, and you evaluate the results, borrowing the processor idea of speculative execution. This pattern is huge for situations where you genuinely do not know which approach is better until you have tried it.

Mutation testing at scale. Spin up hundreds of agents making targeted changes to a codebase, each trying a different hypothesis about why a bug exists or how to optimize something. It is like fuzzing, but semantically directed: instead of random inputs, each change probes a specific theory.

Full-stack consistency checking. Have agents simultaneously hold the contract between every pair of services in your system, constantly verifying that implementations match specs, that error handling is symmetric, and that naming is consistent. These are the things that fall through the cracks in sequential review.

Competitive benchmarking of approaches. For a problem like network latency or caching strategy, you could have 50 agents implement 50 different approaches against the same test harness, and just pick the winner. No reading papers and reasoning about tradeoffs, you settle the question empirically.

Living documentation. Agents continuously reconcile docs, comments, and code. Every pull request triggers agents that check for documentation drift, update runbooks, and surface inconsistencies.

The Harder Problems Cheap Parallelism Creates

#

Synthesis is the bottleneck. If 1,000 agents each produce a pull request, you are back to being the serial bottleneck reviewing them. You need meta-agents whose job is to evaluate and rank the output of other agents, with clear scoring functions.

State and conflict. Agents working in parallel on the same codebase will conflict. You probably want agents working in isolated sandboxes (branches, ephemeral clusters, test environments) with a merge or tournament layer on top.

Task decomposition quality matters more, not less. Bad task specs mean 1,000 agents going confidently in the wrong direction simultaneously. The skill of writing tight, evaluable task specs becomes enormously valuable.

Evaluation functions become critical. “Did the agent succeed?” needs a concrete, automated answer. You cannot eyeball 1,000 outputs. That constraint pushes you toward test-driven development in a serious way.

What This Implies For Infrastructure Work

#

The most compelling application is parallel experimentation on real infrastructure parameters. Spin up ephemeral environments, have agents try different configurations or scheduling strategies, measure actual performance, then tear the environments down. What makes infrastructure hard is that you normally cannot afford to run 50 experiments simultaneously. With cheap parallel agents managing the scaffolding, that constraint disappears.

The practical limit ends up being compute and money, not ideas, which is a fundamentally different world than the one most engineering workflows were designed for.

Things I want to learn about in 2026.

• CometML
• ML model profiling and optimization
• GCP GCS performance profiling
• NVIDIA MPS
• NVIDIA MIG
• NVIDIA time-slicing
• NVIDIA vGPU
• NVIDIA KAI scheduler
• NVIDIA run:ai

Continuous learning only sticks for me when I treat it as a small set of manual habits repeated every day. Waiting for free time or motivation does not work, because busy weeks always win. Five simple practices are enough to keep learning moving.

My learning process

#

The process has five practices, and all of them are manual. Each practice is small enough to fit into a normal workday.

I collect articles shared on Slack that may be relevant to read. Shared links disappear quickly under newer messages, so grabbing the promising ones when I see them is the only reliable way to keep a reading pile.

I identify tools and resources that can help me improve my skills. A better tool or a better explanation makes the same amount of learning time worth more.

I set aside dedicated time for learning each day. The reserved time is what turns collected links and found resources into actual learning, because neither gets read or used without a protected slot in the day.

I experiment with new technologies and ideas. Trying an idea myself is the fastest way to find out whether the idea deserves more of my attention.

I identify areas for improvement in my current skills and knowledge. The identified gaps tell the other practices where to aim, so my effort goes to real weaknesses instead of to whatever topic happens to be easiest to find.

What to Do Next

#

Start with the smallest version of the process and grow it from there:

• Collect the next relevant article link you see shared on Slack, before the link scrolls away.
• Reserve a short, fixed block of time for learning every day, and treat the block as booked.
• Pick one gap in your skills, then find one tool, resource, or small experiment aimed at that gap this week.

This is the routine I follow on every work day, from catching up in the morning to planning the next day in the evening. Most steps are manual, but LLMs assist at fixed points: summarizing yesterday, writing code, and closing the day.

Trigger

#

Every day at the beginning of the (work) day.

Duration

#

8h.

Steps

#

Start of day

#

• Review and correct LLM generated summaries of yesterday’s activities
• Catch up on Slack messages (manual)
• Review PRs (manual)
• Standup (manual)

Throughout the day

#

• Go to meetings (some days) (manual)
• 1:1 (some days) (manual)
• Write code (mainly LLM assisted)
• Reply to Slack messages (manual)
• Review PRs (mainly manual, slightly LLM assisted)

End of day

#

• Continuous learning (manual)
• Generate an end of day summary using LLMs (LLM)
• Daily review (manual)
• Review weekly plan and align (manual)
• Plan next day (manual)

The weekly routine brackets the work week with LLM-generated summaries. I correct last week’s summaries at the start of the week and generate a new one at the end.

Trigger

#

At the beginning of every work week.

Duration

#

5 days.

Steps

#

Start of week

#

• Review and correct the LLM-generated summaries of last week’s activities.
• Weekly planning

Through the week

#

• Daily routine

End of week

#

• Generate an end of week summary using LLMs (LLM)
• Weekly review