michaelrpeskin

I did a similar project just for myself recently, and I think AI interpretation of the IRS is probably one of the ideal projects. AI is generally pretty good at following a spec, and the IRS is generally pretty good at writing detailed specs.

In my case, I had an Inherited IRA that, and this is the first year I have to take a distribution from it. It needs to be emptied in 10 years and starting this year I have a minimum amount to take out based on my age. My goal was to write a simulation of how much I take out each year, what that does to my income taxes, how much tax deferred growth I get by leaving it, etc. I have an optimizer to connect to the simulation, so I could then figure out how much I should take each year.

I decided to vibe it, just for fun. I started very simply: write me a simulation for each year with this much projected growth, etc. The AI asked me some questions like "do you have kids going to college during this time frame?" and did you know that your state has an allowance for this much tax free withdrawal, etc. That took me down a rabbit hole since I didn't know all of those things. I said, go read the IRS code and my state tax code, figure out all of the things that are relevant for my finances (normal W-2 employee, no fancy stuff), and it wrote me a much more detailed simulation than I would have thought of and tied it all to all of the tax things that might be relevant for me.

I was shocked at how good of a job it did, I can (and did) independently verify it since my taxes aren't that complicated. It did find savings that I didn't know were available to me.

I think that this is a great area for AI-based development since it's essentially transpiling detailed IRS specs into code, and that's what AI is really good at.

How do these work when plugged in to only one of the split phases on a US-style 120 system? Because I'm a nerd, I know which legs of the phase go to which outlet in my house, but I don't expect everyone to pay attention to that. I assume something has to take that into account somewhere.

I don't think it's as much as opening up what we _could_ do, it's opening up time so that more can be done.

Slop is too generic of a complaint. Do LLMs write code exactly how I would? No. Is my way right? Probably not. But what LLMs are great at are pre-emptively thinking about edge cases that I forget when writing the code. I'm surprised as how many fewer weird bugs come back to me now after a release. Should I have thought of them? Yes probably, but I don't and they do. So in practice, I do think LLMs write better code than me (if you look at results not the actual code itself).

But more importantly is that it allows me to take on projects that I never would have. Some of them are personal projects, some of them are work projects. I often didn't even consider a project because the time it would take _me_ to do it would not be worth the value. But now that _I_ don't have to do it, I can do more things. At the end of the workday last week, I kicked off a project that I've wanted to do for the last 5 years but could never justify writing it. The LLM crunched for 36 hours, I checked in on it this morning and it's ready for me to deploy next week when I get in the office. Something that would have taken me probably 9 months of focused effort. It would never have been worth 9 months of engineering time, but it sure is worth the 36 hours of background work while I was doing something else productive.

I guess it's not a quantum leap in the frontier of what _can_ be done, but it is a leap in what _will_ be done because the cost/benefit parameters change.

I resemble that remark. The trouble is that I'm now too old and if I ever lose my job, I'll never find another one. No one hiring in tech wants the greybeards.

Thanks for the wording on your first sentence there. I've been trying to figure out a way to get that thought expressed succinctly.

I think with AI coding, what we call "good" code changes. Lots of abstractions really only exist to help load the context into the human brain so that they can solve the next problem. If an agent can just search and find all the places to make a change, or to duplicate code with small changes for the next problem, is that bad? Does is just feel bad because that's not what we're used to?

We use structured looping instead of gotos because that makes sense to us, but the compiler still turns it into jumps in assembly. If our interaction is now at a higher layer, do we need good "code" or do we just need good "architecture"?

I don't know, but it's just something I've been thinking about lately.

I said this in another comment a few weeks back - but, at least for me the "joy" of software development was describing what I wanted and getting it. That used to mean fighting with code and trying to be clever and clean or following the right design pattern. But now, I get "joy" from using English to describe my problem and getting the right answer. When the LLM one-shots it, I get the feedback that I'm describing things correctly and clearly. I'm still getting the same joy just in a different form now. I'm old enough and have been doing this long enough that "giving up writing code" is not sad for me. I'm still expressing my ideas, just differently now.

I've also been doing this professionally for about 30 years, plus another 10 as a hobby/learning before then, so I think I have much of the same experience as you, and I do agree. Although, I think with the advent of LLMs, programming is no longer the hard part. The hard part of programming is the convergence of context management for humans while also presenting it to a computer to do something. Much of data structures and algorithms "best practices" are ways to efficiently get your work done as well as keeping it so that a human has context.

For example, one guy I used to work with wrote this really awesome algorithm about 25 years ago, and I'm responsible for maintaining it since he long retired. I can't go into details, but this is the core algorithm in moving billions of dollars between institutions overnight. It's about 10 screenfuls of c that had been converted from the original FORTRAN 77 with dozens of gotos and weird branching statements and about 20 parallel arrays that store indices for pointer chasing. It's almost impossible for a human to follow (I've actually fed it to an LLM and said rewrite this with for loops and no gotos so I can understand it - and it worked!) but it's blindingly fast. The actual problem it solves can be stated in about three sentences, but programming it was hard because of the context management. The reason that my company keeps getting royalties on this is that it's so hard that they'd rather pay us than write it themselves. But I bet an LLM could write it from scratch now.

So maybe programming is no longer the hard part, or at least context management is no longer the hard part and that humans should move up the chain to help manage the context for LLMs so they can get more done efficiently.

Switching topics a little...much of what I think makes coding the hard part was the tension between big-design-up-front and you're-not-going-to-need-it philosophies. Early in my career I worked in health care and that was BDUF and the coding was easy because program managers spent years defining every screen that would be shown to the users, what queries were needed to fill the screen, all of that. We just took the spec and coded it. Coding was easy. But the failure of BDUF was that it still didn't really match what the customer wanted.

Then enter agile and YAGNI, in that limit, coding is easy, just write what the user story says. But then you have to refactor from what was left behind on yesterday's user story. So smart engineers would cheat a little with YAGNI and say, yes we will put an abstraction in because the next user story. I would say that "good engineers" or "good coders" found that balance in abstraction to move fast but make abstractions not overkill. And I think that's what all the wailing and gnashing of teeth is right now: the good engineers aren't needed anymore.

I can tell an LLM to code something, and as I add complexity it's happy to refactor and manage the context so we don't need to worry about "clean code" or "quality code". As long as what the LLM writes meets the spec, then we're happy.

Ah, sorry long rant and ramble. But I just think the "hard part" has been managing context, and the context we're managing context is just changing. Those good at managing context will be good at coding with LLMs, and those that weren't won't be.

Rather than "managerial" I tend to view it as more "professorial". Maybe it's my academic training (but I got out before I became a professor), but I tend to like to think about my problems in terms of abstractions and invariants and common ways to represent things. I just now describe them in English rather than code. But I do find that LLMs do a much better job the more clearly and completely I express what's in my head. I get that same satisfaction that you mention, but now it's when the LLM does what I want on the first try rather than fighting with it all day.

In the past when my junior engineers were fighting with a bug all week, I always told them the dopamine hit of solving the bug is what keeps you coming back to work for 20 years. Half joking, but the dopamine hit of from the satisfaction getting complex working software in a weekend is like crack to me, we'll see how that plays out long term :)

I think the trouble is living wage means different things to different people.

I look back to my time in grad school. My wife and I were lucky that we were able to get fellowships so we were able to focus directly on school and didn't have to do another job or teach. But it was _tight_! I remember keeping track of every cent in a spreadsheet and we generally were at around $100 extra to save every month (which would then be eaten up by a random car repair or something). We never went into debt, but we really paid attention to our spending. No fancy going out, no travel, no avocado toast.

I think right now people put too much "fun" in the definition of living wage. So yes, I wouldn't want someone to be worried about making rent and eating while being apprentice, but it's also not going to be a glamorous instagram lifestyle.

In 2000-2005 dollars we were making a combined $30,000 a year as grad students. I don't know what that means now, but that's probably the actual value we provided to our advisors (paper writing, conference posters, etc).

My (probably unpopular here) opinion is just the opposite. We need more of an apprenticeship model where you're not paid a bunch because you're still learning, and you probably bring negative-to-zero value initially. When a fresh-out-of-college junior engineer brings in SV style money, the expectation should be that they already know what they're doing.

In the trades you start off low pay because you're generally more in the way than helpful, but then you gain the experience and knowledge to be valuable.

Even the resident-doctor relationship is like this. Resident are overworked and poorly paid because they are more distracting than the value they add, then there's the big reward at the end.

The grad-student/professor model is kind of like this too except for all the pyramid scheme stuff that happens there.

I think most technical fields need to go to this model where the newbie commits to learning and trying to be valuable instead of rest-and-vest. And then once they're valuable they get paid more in proportion to the value they bring to the field.

In my small company we had to switch about 5 years ago to only hiring folks with lots of experience (10-15 years). We tried hiring younger fresh-out-of-college engineers, but "market rate" was too high and they required too much attention from senior staff and it made us unsustainably unproductive. We wanted to mentor and teach the next generation, but we couldn't afford it.

What does the N in NP stand for?

I'm a bit joking, but we've been working in deterministic computation for so long, we don't even think of there being another way.

But seriously, I do view AI as the input to a deterministic machine. Junior engineers (well all engineers) aren't deterministic, and we've made processes to direct their behavior towards making better software. AI agents do a better job of following my processes than engineers. We move up the stack towards testing and verification rather than writing. That doesn't make me sad, after 40 years of coding, I'm kind of tired of it. I have more ideas than I can code, so I'm happy to give AI my ideas and have it code for me.

I had a former manager tell me that all technology problems are really people problems, now maybe all technology problems are all agent problems and we just have to get comfortable with managing agents like we got comfortable with managing people.

In my experience, I'm using LLMs as my abstraction to "junior engineer". A junior engineer isn't deterministic either. I find that if you treat the LLM output like a person's output, you're good. Or at least in my projects, it's been very successful. I don't have it generate more code than I can review, or if I give it a snippet to help me fix it, if it ends up re-writing it like an ambitious engineer would do, I tell it to start over and make minimal changes.

I guess I'm not spun up about the determinism because I've been working at the "treat it like a person" level more than the "treat it like a compiler" level.

To me, it's really like an engineer who knows the docs and had a good memory rather than infallable code generator.

I work at a small company, so we don't have tons of processes in place, but I imagine that if you already had huge "standards" docs that engineers need to follow, then giving the LLM those standards would make things even better.

Recently I did something similar to this on a small part of a project that has built up organically over a couple of years. One developer was getting the output of one program (that we didn't control) into one of our systems. So he wrote a python parser to read the output and put it in a structured format for us to read. Over the years edge cases and options kept creeping in, small features were added one at a time and it kept working.

We had to migrate to a new customer who didn't want the python middle layer, they wanted our software (Java) to read the output directly (don't argue on why this was necessary, just a requirement from a big customer). Since the python script grew up over time by many developers with small changes for new features, it was nearly impossible to understand exactly what it was doing.

I took only the parser code gave it to Opus 4.7 and said "This python code parses an undocumented file format. All of our tests pass and this code is the spec for the file format. Read the python code and create me a BNF document that describes what it parses." I took the BNF and started a new session and said "write me a parser in Java that parses the grammar in this BNF." It got it in one shot. Then all I needed to do is take what was parsed and pipe it into our existing software that took the structured format the python created.

Most of what I do is brownfield work and I really can't put our whole code base into an LLM because of IP issues, but for little things like this, is saves me weeks of work.

Is more code really bad? For humans, yes we want thing abstracted, but sometimes it may make more sense to actually repeat yourself. If a machine is writing and maintaining the code, do we need that extra layer now?

In the olden days we used Duff's devices and manually unrolled loops with duplicated code that we wrote ourselves.

Now, the compiler is "smart" enough to understand your intent and actually generates repeated assembly code that is duplicated. You don't care that it's duplicated because the compiler is doing it for you.

I've had some projects recently where I was using an LLM where I needed a few snippets of non-trivial computational geometry. In the old days, I'd have to go search for a library and get permission from compliance to import the library and then I'd have to convert my domain representations of stuff into the formats that library needed. All of that would have been cheaper than me writing the code myself, but it was non-trivial.

Now the LLM can write for me only the stuff I need (no extra big library to import) and it will use the data in the format I stored it in (no needing to translate data structures). The canon says the "right" way to do it would be to have a geometry library to prevent repeated code, but here I have a self contained function that "just works".

How much of "good engineering practices" exist because we're trying to make it easy for humans to work with the code?

Pick your favorite GoF design pattern. Is that they best way to do it for the computer or the best way to do it for the developer?

I'm just making this up now, maybe it's not the greatest example; but, let's consider the "visitor" pattern.

There's some framework that does a big loop and calls the visit() function on an object. If you want to add a new type, you inherit from that interface, put visit() on your function and all is well. From a "good" engineering practice, this makes sense to a developer, you don't have to touch much code and your stuff lives in it's own little area. That all feels right to us as developers because we don't have a big context window.

But what if your code was all generated code, and if you want to add a new type to do something that would have been done in visit(). You tell the LLM "add this new functionality to the loop for this type of object". Maybe it does a case statement and puts the stuff right in the loop. That "feels" bad if there's a human in the loop, but does it matter to the computer?

Yes, we're early LLMs aren't deterministic, and verification may be hard now. But that may change.

In the context of a higher-level language, y=x/3 and y=x/4 look the same, but I bet the generated assembly does a shift on the latter and a multiply-by-a-constant on the former. While the "developer interface", the source code, looks similar (like writing to a visitor pattern), the generated assembly will look different. Do we care?

I agree with all of those statements - I always told my wife that I'd get our kids a underpowered manual so that they're always busy rowing gears and can't text and drive.

But in the bigger picture, where does it stop?

You had to do manual spark advance while driving in the 30's

You had to set the weights in the distributor to adjust spark advance in the 70's

Now the computer has a programed set of tables for spark advance

I bet you never think of spark advance while you're driving now, does that take away from deeply understanding the car?

I used to think about the accelerator pump in a the carburetor when I drove one, now I just know that the extra fuel richening comes from another lookup table in the ECU when I press the gas pedal down, am I less connected to the car now?

My old Jeep would lean cut when I took my foot off the gas and the throttle would shut quickly. My early fuel injected car from the 80's had a damper to slow the throttle closing to prevent extreme leaning out when you take your foot off the gas. Now that's all tables in the ECU.

I don't disagree with you that a manual transmission lets you really understand the car, but that's really just the latest thing were losing, we don't even remember all of the other "deep connections" to a car that were there 50-100 years ago. What makes this one different? Is it just the one that's salient now?

To bring it back on topic. I used to hand-tune assembly for high performance stuff, now the compilers do better than me and I haven't looked at assembly in probably 10 years. Is moving to AI generated code any different? I still think about how I write my C so that the compiler gets the best hints to make good assembly, but I don't touch the assembly. In a few years will be be clever with how we prompt so that the AI generates the best code? Is that a fundamentally different thing, or does it just feel weird to us because of where we are now. How did the generation of programmers before me feel about giving up assembly and handing it over to the compilers?

I was having almost this exact same discussion with a neighbor who's about my age and has kids about my kids' ages. I had recently sold my old truck, and now I only have one (very old and fragile) car left with a manual transmission. I need to keep it running a few more years for my kids to learn how to drive it since it's really hard to get a new car with a stick now...or do I?

Is learning to drive stick as out dated as learning how to do spark advance on a Model T? Do I just give in and accept that all of my future cars, and all the cars for my kids are just going to be automatic? When I was learning to drive, I had to understand how to prime the carburetor to start my dad's Jeep. But I only ever owned fuel injected cars, so that's a "skill" I never needed in real life.

It's the same angst I see in AI. Is typing code in the future going to be like owning a carbureted engine or manual transmission is now? Maybe? Likely? Do we want to hold on to the old way of doing things just because that's what we learned on and like?

Or is it just a new (and more abstracted) way of telling a computer what to do? I don't know.

Right now, I'm using AI like when I got my first automatic transmission. It does make things easier, but I still don't trust it and like to be in control because I'm better. But now automatics are better than even the best professional driver, so do I just accept it?

Technology progresses, at what point to we "accept it" and learn the new way? How much of holding on to the old way is just our "identity".

I don't have answers, but I have been thinking about this a lot lately (both in cars for my kids, and computers for my job).

This works wonders. I did it accidentally. In March 2020 when my gym closed, I started working out every night in the garage. After a couple of weeks a neighbor who I only ever said "hi" to wondered by and asked if he could join since his gym was closed. After a while more showed up, and now I have like 12 people every day show up. One Friday someone brought a bottle of whiskey and we hung out after the workout and now weekly happy hours are a regular occurrence. The neighbors who don't workout stop by after the workout for happy hour. It's almost become expected and folks schedule their weeks around it so that they can be there for drinks in the evening. As a super introvert nerd, I never thought I'd be the center of community in my neighborhood.

This may just be me, but I hold the opposite view.

When I lived in a rural area with a few acres of property, I was much more social and engaged with my community.

Now I live at the edge of the city in a medium-high density townhouse area with no private outdoor space. Since I can never really get away from people and be alone, I also have no desire to go out and do things and engage with the community.

I think the variability is nice. If I can get home, relax, not have people around, have some private outdoor space, then I can recharge and have the energy to engage more.

One of the things that the tracking taught me was to be allergic to subscriptions. I only have a few where significantly more convenient because I know I'll use it. Outside of our phones (and the kids don't get phones), we have one music service for the family, I'll allow two video streaming services and if the kids want to add one, they have to pick one to cancel, and I have a coffee subscription because the owner lives down the street from me and it's fresher than I'd get in the grocery store.

It's a good point about the routine daily purchases, I never thought of that. But I live semi-rural so I'm not out every day wandering around the city and picking up a snack or anything like that. I imagine that could add up.

Yeah, I only read the abstract and looked at the plots, but this is what I hate about public health papers:

They say the prevalence of virus is down. They don't say that the cancer rate is down (granted too early to tell), nor do they talk about any adverse events or all cause mortality differences (again, probably too early to tell)

The only thing they can conclude is that the treatment given to stop the virus, stops the virus. But they don't mention any tradeoffs.

Not trying to be an anti-vaxxer conspiracy theorist, but good science needs to talk about the whole picture.

25 years ago when my wife and I were poor grad students we had to do this. I tracked everything religiously and she cut coupons for the grocery store. We were generally positive about $100/month at best. Tracking it allowed us to not go negative.

As soon as we got real jobs with a real income, we didn't waste time with that. Our philosophy now is to just make sure that we spend well under our means and not track. We don't penny-pinch, but we still keep some of the grad school "do I really need this?" mentality.

Our normal spending is somewhere under 1/2 of our take-home (including mortgage), so we just don't worry about it and keep saving. It helps that we don't have fancy tastes. It's a nice stress free way of saving and we don't have to get neurotic about tracking every penny either.

Funny you bring this up, I was just talking about this to someone else in a different context. I'm a pretty old dude for programming, I've been hacking in the field since the early 80's, and professionally developing for the last 25 years. Most people would be pretty unimpressed with my skill set, it's pretty much just "linear algebra", and I've basically solved the same 5 or 10 problems over and over again.

The thing that, I think, has given me a competitive advantage is that I put a significant amount of effort into learning the domain I'm working in. I've gone from health care system to theoretical physics to image processing to logistics to financial plumbing to electricity markets to obscure stuff for the War Department, and so on.

The value that you really provide to a customer is deeply understanding their domain and the problem they have in that domain and then translating that for a computer. If you're just taking tickets off of Jira and writing code without context you're no better than an LLM (just kidding...maybe).

So yes, I suggest that whatever field you're working in, you put the effort into learning the domain as well as practitioners in that domain. That's how you become valuable. It's not easy, but after a few iterations you start to see patterns and it becomes easier.

Maybe some of my bias is that when you have a hammer everything looks like a nail - or in my case: when you have a matrix everything looks like an eigenvalue. YMMV.

We did "free" lunch for all here a couple of years ago. The idea is great, execution is terrible. You can't get a la carte free, only the full "FDA approved" lunch is free. So if you forget a drink, or just want to add a snack to your own packed lunch, you go get the whole thing and throw everything else away.

The elementary school tried adding the "share table" where you can put anything you don't want so that someone else could pick it up, but that was shut down because they could assure the feds that everyone was getting a "balanced" lunch.

My highschooler tells me of all the kids going through line multiple times to get pizza on pizza day and then throwing the rest away because they don't want that.

Of course we had a second tax that was approved this year because the free lunches were more expensive than they had planned. Wonder why.

Actually, I think it should be the inverse of that. A CS student should come into CS!01 after hacking for years as a teenager and know how to use something like Linux from a practical standpoint and then college course should be all about the theory and ideas.

I remember when I was 10 or 12 or so hacking with my IBM 8086 and using basic, I accidentally "invented" the bubble sort. In fact, mine was extra slow and inefficient because both my outer and my inner loop went from 1 to N and there was no early exit if no swaps were made. A true O(N^2) algorithm. I didn't now what O(N^2) meant, but I had some understanding the things quickly got slower.

Then later in CS101 I learned about big-O and all the theories around sorting and it immediately clicked because I had a deep understanding of something that I experienced and then could tie it to real theory. The other way around - learning the theory before the experience - wouldn't have worked as well.

To tie it to your comment, you should have a deep experience with your OS of choice and then when you go to school, you learn why things are the way they were.

When I say this I often get accused of gate keeping, but I don't view it that way. I look at it as other types of majors that have existed longer than CS. I often make an analogy to music majors. I can't enroll as a freshman and say I'm going to be a music major without ever having played an instrument. People get accepted to a music department after they demonstrate the ability (usually though the equivalent of hacking while they were kids), and in their music classes they learn theory and how to play different instruments (just like learning different OSes or languages).

I kind of feel that CS should be the same way, you should show up to CS101 knowing how to do things from deep experience. You may not know any of the whys or theory, that's fine, but you should have experience in doing.

To tie it back to the parent: you should come to CS knowing how to run Linux, maybe because you copied configurations or scripts from the dark corners of the internet. And then the CS classes should be around why it's all that way. E.g., you know that to schedule something you use cron; and CS would be a discussion around how generic OSes need a way to schedule tasks.

But I think he's the only one to have done it right. I've never seen velocity tracking correct for measured inaccuracy in each developer's estimates. I've tried so many times to implement his EBS approach, but no one wants to do it.

For extra fun, in C you can write i[a] since addition is commutative *(i+a) == *(a+i)

Yes. I do this a lot when writing linear algebra stuff. All the math texts write things in 1-based notation for matrices. The closer I can make the code match the paper I'm implementing makes life so much easier. Of course there's a big comment at the beginning of the function when I modify the pointer to explain why I'm doing it.

Sorry, you're right. It's been so long since I used it, I forgot that it wasn't a .com domain.

One trick that I always fall back on is to make a dependency graph. In meetings I used to pull up yuml.com but now I use mermaid. You can just start typing text and arrows and it renders in real time what depends on what. It's great in a live meeting to help focus people on where the problem really is, or in documentation to show why a change here will affect something there.

Both yuml and mermaid don't get you control over layout. I think that's a feature. If the layout engine can make a pretty picture that means your dependencies aren't too complex, but if the graph looks terrible and complicated, that means you're system is also probably terrible and complicated.