koliber

Every software developer will be a manager of one or more AI agents. Managing AI agents will turn out to be surprisingly similar to managing people, except for the drama, illness, and tragedy.

No. The cost of one programmer’s hour of work compared to the increase in price of RAM is not very big. One is a variable cost one is fixed.

It’s a funny comparing commutes back then to commutes now. But it does not take a lot of imagination to see that back then people did not isolate themselves with newspapers while buying food at the grocery store, standing on the crosswalk or in a myriad of their situations where we have opportunity for micro interactions with other people. In other words, looking only at commutes is nit picking.

How much RAM did the local machine have?

I was not thinking about real $ costs, but rather the cost of the hours of the people who had to deal with this BS.

Over the past 9 months I've been advising one small client of mine on AI adoption, and engineering maturity in general. They have a team of 5 engineers. One very capable lead and 4 ICs. They did not use AI at all before.

It was a whirlwind of a ride as the company caught up on 10 years of engineering maturity and 3 years of AI usage progress in 9 months. The improvement in output has been noticeable, and the quality has not dropped. In short, cycle time and throughput rose and quality remained stable.

One of the things we are talking about is the future. As the team learns how to use AI well, the amount of code will grow at a faster pace. The focus is now on writing things we really need, and ensuring the quality does not degrade.

We are trying to get the engineering team to lean into understanding the product and business domain, and also adopting a QA mindset.

One of the engineers is not interested in the business domain. He loves typing code. I am afraid that within six months it will not make sense to have him around. He is relatively junior and wants well-specced tickets, and is reluctant to use AI. Right now, Opus writes better code than him, and solves business problems more acutely, with less time spent on writing careful specs.

If he gets fired, the budget will likely be re-allocated to AI.

In 7 months, it will be fair to say that we replace 20% of the team with AI. If that happens, it will have been a thoughtful process focused on upskilling willing employees, and not a boneheaded hype-driven decision. But it will be judged on the summary and not the process that went into it.

I'm being a little facetious when I write this, but bear with me:

Let's say I have daily backups, and get 10x done each day by being reckless and risking an "rm -rf", and let's say there's a 1% chance of an "rm -rf". I break even after 2 days of being reckless even if I get unlucky and on day 2 it wipes my drive. I spend day 3 and 4 recovering, and am still 6 days ahead based on the 10x work I got done on day 1.

What if I have a 50 day streak of not hitting an "rm -rf"? Early retirement?

I guess the work on day 1 should be to build a proper sandbox and drop the chance of an "rm -rf or worse" even down to 0.001%.

I wonder how much money this agent wasted on the DN42 side? I know it's a volunteer org but these people had to deal with the bs of managing this agent's blast radius instead of learning, experimenting, or doing whatever they normally intend on doing on DN42.

Tally it up and send a donation request to the agent operator.

The problems with inheritance tax is that they can be avoided through trust structures and insurance schemes. In theory it's a good tax, but in practice many wealthy people figured out how not to pay it.

I own a domain and have a catch all email. I routinely get emails from Microsoft and Google's official email addresses telling me that some account will be closed, or some other account notifications. I never created these accounts, and when I try to log into them or do a password reset, it does not go anywhere. It's been a minor mystery why I keep getting these emails for a while.

The Microsoft emails are coming from microsoft-noreply@microsoft.com so it's a bit different than in this article.

Supporting is a word that means many different things.

It’s ok to stop providing updates to old software and hardware.

It’s OK to not support ancient devices when writing news software.

It’s not ok to make old devices inoperable if they are using the old software and don’t need updates.

Will my old Kindle stop being able to show me the books I bought and downloaded to it? Or will it become impossible to buy new books? If it’s the earlier, it’s borderline criminal. If it’s the latter, I’m unhappy but understand realities.

I’m not an accountant and what you’re saying is probably right. However, if you hire an engineer to do R&D, build systems, and take R&D tax credits, it “feels” like capex.

Replace “Claude code” with “programmers” and you get what we’ve had up until now. It’s all just moving quicker now.

You don’t need to teach anyone about this. The wealth tax should apply to extremely wealthy people, not everyone.

If you accumulated a fortune, there was some skill at play. There was also considerable luck and some exploitation. The wealth tax is a way of paying back for the luck and exploitation.

You will still be extremely wealthy.

Paul wants to play the fairness card. Life is not fair and those who accumulated massive fortunes won the lottery. Don’t let the massively rich conflate issues. Don’t get fooled.

Is it capex of training new models and hiring people for 250mln pay packages? Or is it opex running inference?

Absolutely right. I had a "math moment" myself. I was thinking margin instead of markup.

EDIT: [ IGNORE THIS COMMENT -- IT IS WRONG - I had a "bad math moment" myself ]

The math seems off. How is 7.8 million vs 4 million 95% more expensive. Article makes good points but I doubt the numbers as they don’t add up.

Still agree with the conclusion though.

You’re right and that’s intentional. Japanese companies don’t optimize for efficiently but for longevity. Sometimes those things go hand in hand. Sometimes they don’t.

The article makes a good point, but it's based on a polarized view that people make good judgement and AI is incapable of making good judgement.

I've worked with people who demonstrated below-average judgement, and I've seen cases of good judgement from AI. I think if a company can identify the poor performers and part wit them, there is a decent chance that the remaining people with AI in hand can more than make up the difference.

Now given the logic that you can't be dependent on any one service to run your SaaS, how does Railway convince its customers to run their SaaS on a single service?

You can have an offboarding doc even if you don’t have employees. It will apply in the future once/if you do. It will be silly and useless now, but you can check it off as a YES.

How will you know that it produced correct code if you don’t know how to write it yourself?

If a behavior is undefined, the theoretical answer to this could be anything, including -123, 500, or 0. We are just lucky that the compilers choose a more sane version of undefined behavior in practice.

I don't. But many others do. The only thing that let's banks and other companies know that you are dead is a piece of paper called a Death Certificate.

A doctor friend of mine once joked that it would be really cruel to issue a death certificate for someone who is alive. This seems to be a soft version of that.

The only thing that would be crueler is to revoke someone's birth certificate. "Sir, you never existed in the first place."

What you are talking about is in a large part authentication. You can do authentication using an external service and still have your user table locally. You can also do authorization locally with a local session table while leaving authentication to a SaaS.

Many engineers with a long career have probably thought about becoming a manager at one point. A large portion of them decided to stay in the IC (individual contributor) track because they did not like some of the aspects of being a manager. Some decided to stick to the IC role because they liked creating code.

With AI, every engineer will need to become a manager to manager one or more AI assistants who do a lot of the work. The good news is that this will not involve dealing with performance reviews, psychological problems, and raises. You will also remain close to the code.

Look at the manager role again, and see which parts of it will be needed to manage AI agents. Learn those parts from standard management books. You will kind of pivot, but still remain close to the code.

On the other hand, if all you enjoyed is typing in code, but hated working with product people to understand the intent, doing code reviews, or building software that is easy to QA, there will be fewer and fewer such jobs.

She is a woman.

There are so many shades of gray in freedom of speech. In free European countries the police are also not at the door of outspoken government critics.

If you are alluding to dictatorial European countries like Russia and Belarus, the US is miles away and moving in their direction. Compared to Western Europe, there is no difference.

Lately I keep hearing the same thing over and over: the things that are good for managing a team of devs are good for LLMs.

Good test cases.

Clear and concise documentation.

CI/CD.

Best practices and onboarding docs.

Managing LLMs is becoming more and more similar to managing teams of people.

Bad UI plagued software development since ages immortal. The reason is not AI. Good UI design is a skill (or art?) and not an afterthought. But most people do not see it that way and that is why things are the way they are.