Claude for OLGs: Huggett & Ventura (2000)

Claude + VFI Toolkit = The Best Posse Cut You Ever Heard

Yesterday I downloaded Huggett & Ventura (2000) - Understanding why high income households save more than low income households

I gave Claude the pdf and asked it to replicate the model using VFI Toolkit. The paper solves OLG models with two endogenous states, savings and life-time earnings (to which pensions are indexed). In just three hours, code for the core results was done! Four different OLG models, most with two endogenous states, all in three hours!!! My personal time was nearer a half hour, and the rest was Claude Thinking/Flibbertgibbeting/Meandering/Accomplishing/Etc.

Here is all the code and the pdf: https://github.com/robertdkirkby/HuggettVentura2000

Turns out VFI Toolkit is like a superpower for Claude. Because the toolkit provides a clean structure for models, Claude can understand how to translate models into the toolkit setting. VFI Toolkit hides most of the numerical methods, so Claude just has to figure out the state-space, action-space, ReturnFn, FnsToEvaluate and parameter values. All of this VFI Toolkit structure means the remaining problem is one Claude can handle.

If you’ve done much AI coding you will know that when you ask for a few hundred lines and provide lots of structure, Claude will get things 90+% right, and the debug of the remaining 10% is easy as you can see the whole code. This is what happens when building OLG models in VFI Toolkit. Without VFI Toolkit these models would require thousands of lines of code, and Claude will not only be down nearer 80% right, but it will be a nightmare to debug. VFI Toolkit acts as a superpower for Claude by providing structure and slashing the number of lines of code to be written.

I wanted a hard test to demonstrate the power of Claude + VFI Toolkit. So I chose Huggett & Ventura (2000) as it requires the use of ‘experienceassetz’ which is a new feature for which no public examples yet exist.

Claude did not require much work from me, but nor would it get far without me having intermediate-level knowledge of both OLG models and VFI Toolkit. I was using Claude on my laptop, Claude could not actually run Matlab (no Matlab MCP installed), and even if it could there is no GPU so it would not be able to run the model code (hence why I don’t bother installing the MCP). I ran the code on my desktop, which syncs to the laptop with Dropbox.

The next post explains the main things that you as user need to be able to do to get good performance from Claude + VFI Toolkit. The post after this is just me shooting from the hip about what all of this means for solving Economic models going forward. A few educated guesses.

3 Likes

Summarizing the session: Claude got everything up and running insanely fast and easy. And then because VFI Toolkit provides good feedback on what is going on during solving things, it was easy to see the issues and then did not take long to track down and resolve the bugs. The feedback for general eqm and the ability to trivally spin up life-cycle profiles, etc., really helps.

There were four main things I think Claude missed:
i) Claude wanted to create a HuggettVentura2000_FnsToEvaluate.m. When I asked why not just do it as individual lines it realised this was wrong and they should just be done mostly as single lines creating subfns to call where the function would be complex.
ii) Claude regularly misses that tricks can be used to eliminate GeneralEqmEqns. When I pointed out that if it replaced ‘ybar’ with ‘w*ybar’ then it could rewrite some code and eliminate one of the GeneralEqmEqns it saw what to do and implemented. But it missed these kinds of tricks originally. I eliminated two GeneralEqmEqns in this way. I have left the ‘LaborMarket’ in GeneralEqmEqns so you can see what I mean, dropping this is a standard trick (see Aiyagari model codes) but Claude missed it. The code remains correct with the extra GeneralEqmEqns, but it is inefficient.
iii) In most models I do with Claude+VFI Toolkit, it often misses that you want to use vfoptions.gridinterplayer=1 and vfoptions.divideandconquer=1. Make sure it uses these were appropriate.
iv) Claude hard-coded it’s own Tauchen discretization using ‘normcdf()’! I had to laugh at this one! I told it to use the discretize commands instead. [It’s code was correct, but makes things hard to read as took two dozen lines instead of one.]

Two general VFI Toolkit tips. I tend to set vfoptions.verbose=1 the very first time I run ValueFnIter in a script, then set back to vfoptions.verbose=0 next line as otherwise will be way to much info when doing general eqm etc. Setting heteroagentoptions.verbose=2 prints parameters at start of each iteration, if the general eqm errors this is helpful as now you can just use those parameters and create V, Policy, StationaryDist, AllStats, etc., and see what went wrong.

If you want to do this yourself, here are what I would say are the main steps to follow:
Create folder containing pdf of paper (and replication materials if those exist)
Point Claude to paper, tell it the plan is to replicate this paper using VFI Toolkit, and it can find the toolkit, plus lots of examples, at https://github.com/vfitoolkit
[notice, link is to the ‘org’ not the toolkit itself, so AI will see all the examples and replications]
Ask Claude to show you a proposed plan for what the model action space and state space are, and build a script solving for V,Policy,StationaryDist,AllStats, and AgeConditionalStats for the core life-cycle model of the baseline model.
Run the code, check that works, look at contents of AllStats and AgeConditionalStats to sanity check what is happening. Check that grid interpolation layer etc are used appropriately.
Ask Claude to build code to solve the OLG model
At this point you are largely done although for sure some cleaning of the code will improve things, you might next ask for code to create some of the Figures and Tables (“create Table 7 of the paper, based on what other replications do”), or you might ask for code implementing the policy-reform exercise, etc.

In short, having a user who has a good idea of what they are doing —both in terms of understanding OLG models, and in terms of being roughly familiar with VFI Toolkit— is absolutely essential. Left on it’s own Claude will get the code 90% right, but that still leaves the results 100% wrong!!! But knowledgeable users can now just spin up OLG models with insane ease! To repeat, I just built four OLGs in sub-three hours!

PS. Because the second endogenous state has a single-valued decision variable it is in effect an exogenous state. Clever coding could further take advantage of this, but model solves easy enough as is, and the current approach makes it much more obvious how you can endogenize the labor supply

2 Likes

Now for me to talk shit about what all of this means. Half of this post will probably end up coming true, and the other half will not. I am just going to talk about what this means for how to solve Economic models. I won’t try to guess what it means for what we will do with the models, or how it will change the Economics Profession. What follows is me trying to understand how AI coding is going to change Economic modelling, first thoughts not final thoughts.

Imagine that “all” Economic models are a cloud

At a high-level there are two approaches to solving each Economic model: we can hardcode the solution, or we can use Deep Learning to solve.

In a head-to-head for any given model, hard-coding will win. It takes advantage of known properties of the model as well as various tricks that are encoded in the hard-code. By contrast, Deep Learning (DL) will have to expend a lot of compute trying to understand the shape of the problem on the way to solving. Both can solve the model, but the DL is just much more compute intense, and so slower.

But much as compute intensity and thus runtimes are the Achilles heel of DL, the Achilles heel of hard-coding is that someone has to hard-code it! This means one code for every model. There are tens or even hundreds of thousands of models. Dynare probably solves a few thousand, VFI Toolkit solves a few hundred by my rough count. And so most models are just not going to be hard-coded, and DL will be used for, say, 90% of models. Our cloud of models thus looks like

If you asked me between one and five years ago, this was the end of the story. VFI Toolkit would hard-code a core of models, maybe even a thousand of them! But then AI Coding arrived. Last week I AI coded a few dozen models in an afternoon, which in the past would have taken a week or three, and it wasn’t even the main thing I was doing that afternoon. Suddenly with AI Coding it is easy for VFI Toolkit to solve a few thousand models, and getting there will only take a year. Hard-coding ten thousand models seems do-able given three or four years. And just like that the red circle has been renamed ‘Hard-coded with AI assist’ and now it has grown to fill most of the cloud

AI Coding has made it not just possible but likely that we can simply hard-code just about every Economic model we want to solve. We can even code each one a few times to find the best algorithms and rather than users having to understand all the algorithms the hard-coding simply embeds and records all that expert knowledge of how to solve each model. The Achilles heel of having to code each one has been ameliorated by AI coding, dragging us back to the Styx for another dunking.

Where does this leave Deep Learning, seemingly relegated to the dark fringes of the cloud? First, Deep Learning will still play an important role in solving some of the most advanced models, where people have compute to throw at them and little idea how else to solve them. Second, it suggests an important new role for Deep Learning. It is understood that one of the strengths of Deep Learning for solving models is its ability to find dimensionality-reductions. Deep Learning can be used to solve a model type once, find and understand the best tricks for that model —say a change of basis, like state-space versus sequence-space, or a functional form, like Chebyshev polynomials or Akima splines— and then these can be hard-coded on a model-by-model basis. Hopefully we see some work take up the challenge of using Deep Learning to fulfil this new role. Third, I may be wrong and instead Deep Learning changes the kinds of models Economists solve, more Q-Learning AlphaGo models that are amazing at winning Go competitions while being largely a black-box on tactics. I put low odds on this, Economics is much more interested in understanding and in (non-local) counterfactuals than other areas, as evidenced by the stranglehold of the Lucas Critique in Macroeconomics.

AI Coding also increases the value of improved algorithms that we can hard-code, because it slashes the cost of adopting them. We can even set them as options that the user can choose from to solve the model. VFI Toolkit already has ‘divide-and-conquer’, ‘grid interpolation layer’ and ‘fastOLG’, and it benefits immensely from having adopted the Tan improvement. The advent of new algorithms, like Endogenous Grid Method, BKM, and Matched-Expectation Path means rewriting all our hard-coded models, but with AI Coding this is no longer a daunting prospect, it is something we can reasonably do.

That’s my guess at how the cloud of Economic models develops. For sure I am half-wrong — as Yogi Berra (probably didn’t) say, “it’s tough to make predictions, especially about the future.” And while I’ve read a lot of papers on Deep Learning I’ve never done more than dabble with it. But the through-line I’m most confident about is that AI Coding pushes the binding constraint away from writing solvers and onto everything else — choosing models, interpreting them, knowing which question to ask. Should make for some fun Economics!

—--------------
Give me some examples of this head-to-head between hard-coding and Deep Learning you say? Let’s consider global non-linear solutions of models with incomplete markets and aggregate shocks. DeepHam takes 30-40 minutes to solve the Krusell-Smith 1998 model. Abbott and Nam fuse hard-coded finite differences onto DL and get 10 minutes. Hard-coding the Matched-Expectations Path and suddenly it takes just one minute (beta functionality in VFI Toolkit, will be public towards the end of this year). All three of these runtimes use very similar GPU hardware. More generally, just look at the amount of compute being used in the average DL paper, you can easily see how demanding they are.

What might 'using Deep Learning to find dimensionality-reductions look like? Not quite sure, but Section 3.2 of Gordon-Wilson (2025WP) discusses the ‘effective dimensionality’ of Deep Learning solutions, and it makes sense we could develop further tools for seeing what the dimensions are. Once we know the dimensions a solution should occupy, it makes sense you can hard-code solution methods that directly exploit these known dimensions.

A quick clarification on what I mean by hard-coding a model. I do not mean writing code for a specific example/application like HV2000. I mean writing code that solves a specific model-framework with a specific algorithm. For example ValueFnIter_FHorz_QuasiHyperbolicN_DC1_GI1_nod_raw() from deep inside VFI Toolkit. This code solves a finite-horizon value fn problem (ValueFnIter_FHorz) using divide-and-conquer and grid interpolation layer on one endogenous state (_DC1_GI1) for a model with no decision variables (_nod) and a markov shock (implicit) for Naive Quasi-Hyperbolic discounting (note the N). If you look in the same folder, there are sixteen codes solving with/without d/z/e and Naive/Sophisticated Quasi-Hyperbolic discounting. Neighbouring folders do _DC1 and _GI1, separately, and one folder up and the codes for pure discretization. When I say I wrote a few dozen models in an afternoon, these are what I am referring to, codes that solve model-frameworks. This is why I think AI Coding massively increases the returns to building toolkits, because we can now code thousands of frameworks.

I should probably clarify that I am in favor of the stranglehold that the Lucas Critique has on Macroeconomics :smiley:

2 Likes

Question: is it enough to point Claude to the online repo or do you have to have everything downloaded in a local repository on your computer and tell Claude “look at the vfi toolkit here on my computer?”
When I use codex, sometimes it runs into problems checking web links.

Claude’s ability to follow links seems to be heavily website dependent. This discourse forum, like most academic journals, deliberately blocks crawlers, AI, and ‘non-humans’. So Claude cannot access directly and it’s indirect attempts are hit-and-miss. But Github does not attempt to block in any way, so Claude has no issue accessing everything on github.

But you are right, you can always just git clone the entire VFI Toolkit github org to your harddrive and tell Claude to look there. Main reason I don’t do this is that those things are spread all over different parts of my harddrive, so would take me longer to explain.

PS. This forum once got spammed by bots spinning up accounts and creating posts and I had to spend a whole evening deleting accounts as fast as they span up while blocking the IPs they came from. The ‘make non-humans life difficult’ is mainly about avoiding that kind of thing, not because I don’t want AI to see forum. In fact I would rather it could read it easily as will help it code better with the toolkit.

1 Like

I think the link points to another paper, not to Huggett & Ventura (2000).

Really nice replication, by the way. Happy to notice that now the toolkit can handle lifetime earnings as a second endogenous state variable, using the “experience asset with z” feature.

1 Like

Haha, oops. Fixed. Thanks @aledinola

There is ‘experienceassetz’ and also ‘experienceassete’ and ‘experienceassetze’. I plan to add a Life Cycle Model 43 to Intro to Life-Cycle models showing how to use the ‘experienceassetz’ for pensions that are indexed to lifetime earnings.

3 Likes

Can the toolkit handle two experienceassetes, such as one refers to the human capital accumulation, and another is the record of the lifetime earnings?

1 Like

No, but if you want this let me know and I can implement it. Not currently on my list, but happy to add it to my list.

2 Likes

My preliminary idea is to consider both aspects in a life‑cycle model. For the sake of speed, I am currently coding the model in Fortran. However, I am interested in using the VFI Toolkit for my next research project. I would greatly appreciate it if you could add this feature to the toolkit. Please consider it for your development list.

2 Likes

Here is a first version: Dropbox

Run the LifeCycle_DoubleExpAsset.m

As comments at the top say:

%% Life-Cycle Model with Double Experience Asset: Human Capital and Lifetime Earnings
% The agent chooses hours d in {0, 0.5, 1} (not working, part-time, full-time)
% and savings a' each period. Two endogenous states evolve as experienceasset via aprimeFn:
%   h: human capital, h' = hcgain*d + (1-delta_h)*h
%   y: lifetime earnings (cumulative), y' = y + working_j * (w*kappa_j*h*d)
%      (y freezes from age Jr onward; working_j is 1 in working ages, 0 after)
% Pension at retirement is a fraction (pensionrate) of average lifetime
% earnings, i.e., pension = pensionrate * (y / (Jr-1)).
%
% This is a demo of the multi-dim experience asset (vfoptions.experienceasset=2). 
% The agent's aprimeFn returns both h' and y' via a 'whicha' selector slot
% (whicha=1 returns h', whicha=2 returns y')
% Note: this 'whicha' is an additional input to aprimeFn that is needed when using more than one experienceasset

%% How does VFI Toolkit think about this?
% One decision variable d (hours worked)
% Three endogenous state variables: a (savings), h (human capital), y (lifetime earnings)
%   a is the 'standard' endogenous state (a' chosen directly)
%   h, y are 'experience assets' (h', y' determined by aprimeFn)
% No exogenous (markov) state.
% Age: j

Currently I only implemented the version with no other decision variables (other than those entering the experienceasset). And no shocks of any kind. Also only works for experienceasset. Haven’t implemented divide-and-conquer (DC) and grid interpolation layer (GI).

Let me know if this looks like the kind of thing you are after? If yes, tell me which experienceasset (the baseline, or experienceassetz, or experienceassete) and which combo of shocks you need. I will implement that with/without d1, and with DC and GI. I can go implement the case you want next week.

I will go and implement all the cases at some point, but not until late July at the earliest. But I am happy to implement a handful of cases now so that you can use them.

You can see test.m and crosstest.m in the same folder that show the tests I have currently run. Obviously though this is not nearly as well tested as most functionality.

PS. Once I thought about it, I realised it could be done by a relatively minor change to how the aprimeFn is handled, and so it is much less work that I was expecting it to be. Hence why it didn’t take long.

PPS. Is very fast because the grids are tiny. Is purely illustrative of how things work.

PPPS. Model is a bit stupid as it is endogenous labor without any utility of leisure (Claude’s fault :P) but it is just to illustrate how to code and not a model to take seriously, so it is fine.

2 Likes

Lecture notes on Markov processes for modeling heath/disease progression from Auckland University cites Niels Bohr as having said “It is very difficult to predict anything–especially the future” in 1956.

1 Like

Hi Rob, sorry for the late reply. I was away at a conference for a few days. The sample code runs perfectly. A big thank you for your excellent work!

Basically, the agent in the model would face three income (productivity) shocks:

  1. permanent shocks (heterogeneous abilities);
  2. persistent shocks that follow an AR(1) process;
  3. temporary shocks that are i.i.d. normal.

So it is essentially a standard stochastic OLG model. There is, of course, an endogenous human capital accumulation function, which can take either a learning-or-doing (LOD) or learning-by-doing (LBD) form. I haven’t yet thought about whether it should allow for stochastic returns to human capital. It doesn’t seem crucial to me at this stage.

PS: This is a future research project, so there’s no rush at the moment. The end of July is perfectly fine with me.

2 Likes

Okay, 1 & 2 means it will be experienceassetze to keep track of the life-time earnings and human capital accumulation (you could always have the human capital accumulation aprimeFn ignore the iid shocks if you wanted).

I have actually been working on two experienceassetze over the last week for a different idea where I just wanted to see how the runtimes would look like, so that is mostly done already. I will try create an example to put here.

2 Likes

Here is dropbox folder containing ‘LifeCycle_DoubleExpAssetze.m’ which does the markov and iid, in model with ‘savings’, ‘human capital’ and ‘lifetime earnings’ (so pensions can be indexed to lifetime earnings). Does not do permanent types, but that is standard toolkit feature and an easy extension.

DC+GI works for this (both are applied to the standard endogenous state ‘savings’). I think that is all the features that are required, but if you see anything missing in terms of what is needed to run the model just let me know.

1 Like