If you are doing your job as a manager it’s the scariest career possible. There is no realistic fallback to lower paid IC work after a certain amount of years. Your job is to enable others, not do things yourself.

There are shades of grey and you try to keep skills at least honed a little here and there doing R&D and side projects - but it’s just not the same as day to day production line work.

And of course some people start at a much higher baseline of skill than others. The impact is largely the same though over time.

This is by far the single largest caution I give to skilled engineers who talk to me about moving into a management track. It’s a decision not to be taken lightly.

I have plenty of complaints about Apple, but the Airpods experience is one the stickiest user experiences they have and would be one of the harder things to give up if I moved back to Android.

University libraries of course might be a good exception to this rule. But your local public library should be a way to make reading accessible to the average middle to lower class family. And that means providing the materials they want to read - not what you think they should.

It's always going to be a balance for librarians. They don't get to operate in ivory towers disconnected from those local taxpayers whom fund them.

As a library-funding taxpayer myself, I find it very depressing that the selection in my local libraries is so lacking. Hence my remark about the vast superiority of second-hand bookstores for just about any topic.

It's pretty classicist to assume that only rich people are reading those kinds of books. I have plenty of friends who struggle to pay rent who read dense stuff like philosophy, lit. theory, etc. This whole David Brooks style paternalism drives me crazy.

Why should I support a public entertainment center? The original American libraries were created to make valuable and educational works accessible to the public, not pulp. Library systems all over the country have discarded most of this stuff in favor of political, romance, mysteries and kids books. Abandoning their original mission is exactly why their public support has collapsed. Nobody cares about a place for homeless people to browse the Internet or to check out video games and movies.

> But your local public library should be a way to make reading accessible to the average middle to lower class family.

"Reading" is already maximally accessible, nobody needs a library to do this. Kids are reading reams and reams of web fiction. If anything, the increasingly low quality of library fare is related to the poor reading level of Americans generally - children's books have become especially atrocious, but even pulp mystery fiction is written on a very low reading level. “We have to get them to READ” is a completely pointless and meaningless goal if the public benefit is to keep up romance fiction publisher profits.

https://www.reddit.com/r/antiai/comments/1rnjx1e/i_found_thi...

https://www.governing.com/artificial-intelligence/how-local-...

This lets me mess around with random experiments as I "catch up" on how to find various (mostly silly) uses for the technology.

That and much less worry about being banned without warning for not using approved harnesses as I try random stuff is a giant plus as well.

I assume they have lots of spare compute and less demand than Anthropic as it's obvious they are subsidizing my usage for now. But it lets me start off with "giant context window" type playgrounds which give immediate moderate effectiveness, then I can figure out how to tighten it up and reduce token burn from there.

Standing meetings tend to devolve into performative uselessness. And they add stress, interruptions, etc. And worst of all - they tend to let people have a false sense of accomplishment afterwards.

1:1's I think can be useful for a certain type of employee, but should be 100% at that employee's discretion. The only use I see for them for that type of person that they have a predictable slot held open on their manager's schedule in the event they need to actually execute it. Most of them should be skipped or there are probably other issues in the employee:manager relationship.

I understand I am the odd man out when it comes to "meeting culture" but the more I get stuck in a myriad of standing meetings the more I have ossified my opinion on this subject. Meetings are not productive work. The older and more experienced I get the more useless I think they are.

A random meeting called because there is an issue to discuss and get a decision made on? Totally fine. Those are useful.

Peak COVID it was obvious inflation was going to hit hard in some sectors. So I loaded up on durable goods like HVAC, hot water heater refreshes, major appliances, and even pushed some home maintenance forward where labor and materials were likely to skyrocket.

I certainly made a bet, and a lot of it had to do with "lifestyle" - in that I wanted upgrades of most of those things either way over the next 5 years. I just pushed the spending forward by a whole lot since money was going to be rapidly worth less and those specific goods I predicted were going to outpace generalized inflation. I also wasn't certain my income was going to be secure for the long haul so I'd rather spend the money while it was still regularly coming in vs. being stuck later.

Same went for looking at laptops late last year. Since I'm in the IT industry it was obvious memory and flash storage prices were going to go parabolic, and consumer pricing was lagging the market at the time. If you saw this happening you'd be pretty silly to sit and wait on it for another 6mo.

And the same goes for investment class assets. As those outpace wage growth by multiples, your salary becomes less and less important. Once your salary is in the low double digits of your total income in a given year I'd say it's probably time to take a hard look at continuing to work. The juice no longer becomes worth the squeeze. And asset price inflation means this decision point is brought forward years - perhaps decades - for some people.

It obviously doesn't mean go YOLO in your 20's. But if you're 58 years old and were thinking you'd work another 8 years - perhaps it's time to reevaluate the situation. Adding another 3% a year to your dragon hoard via wage savings might not pencil out how you think it will.

This very well summarizes my current thinking on the subject as well. And most of my career has been playing the role of technical debt nazi. Much to the detriment of my earning potential.

Does AI make incredibly inefficient code most of the time? Yup. But it does it at lightspeed with minimal effort.

I think many software engineers forget they exist to get real things done (in many cases at least) and they are a cost center for most businesses. If your end product is not selling software, very few people actually Doing the Thing(tm) will give a single solitary care about code quality or maintainability when they can just spend 30 minutes and $15 worth of tokens to fix it.

It won't take over everything, but I've already seen otherwise very intelligent go-getter type folks who are not technical or know how to code made extremely useful things for themselves and their small little enterprises. And this will seemingly only get better and more efficient.

For someone who really does love the idea of well architected and future-proof code this is just icky to even say or consider. But I'm coming around to this is the future for the majority of software for most places. And it may have the ability to seriously even the playing field for small enterprises in some industries.

I'm currently using it to implement a zillion side projects at home I've been "meaning to get to" for years. It makes incredibly silly unmaintainable code most of the time - but I learned to not care, and just tell the AI bot to fix it/add to it as I go along. Worst-case I spend a single night deleting it all and starting from zero to "refactor" an entire thing.

I am suprised to hear people so naive they expect their token usage to stay flat if code quality and maintainability starts falling exponentially?

What if to fix 2 bugs your LLM starts adding 50 new ones? Will you tell your customers in supports channel "sorry software is finished, if we try fixing anything, everything else might break, not worth it". Or "we can probably fix it, but our AI usage will raise so much we need to up the subscription 3 fold, you choose".

The speed at which LLM codes is only comparable to the speed at which they add garbage to your repo. If you stop caring about maintainability, you also stops caring about your AI/LLM related bills and the viability of your project past the PoC stage.

Another thing though is selling software in the first place will soon become tough proposition outside of a few niches.

There's no reason to think that quality and maintainability will start falling exponentially. On the contrary, these models get better every couple months, and 99% of software isn't actually that complicated. There's just no reason for the fear-mongering that fixing 2 bugs will cause the LLM to add 50 new ones.

Not 50:1 but it does happen

One billion percent. I think the vast majority of the anti-AI sentiments I hear from software engineers comes down to them caring more about playing with their tools than actually solving the problem.

The tools we "play" with, we developed and refined over decades, and we did so for good reason. They all emerged out of real problems that needed solving in the real world. Many are born out of experiences where things went terribly wrong.

AI bros and execs drinking the kool aid are gleefully dismissing the warning signs of millions of experienced developers, and don't think that maybe, just maybe, their billions of hours of experience may mean they know some things they don't.

The landing will be brutal, and I have my popcorn ready.

This hits the nail in the head.

Detractors often hang on to examples of coding assistants making mistakes or output subpar code, but they somehow miss the fact that coding assistants can also be prompted again and refactor whole swaths of code just as fast as they introduce oopsies. This means that the worst case scenario implies fast convergence to an acceptable outcome, and from there also fast iteration to improve upon that.

The only way I see AI coding working in the long run is if we go back to a Waterfall/BDUF process and having actual engineering. Let engineers really own the architecture. Enforce that any new feature - no matter how small - to be specced out with complete sequence diagrams. Ensure that every new software package needs to be put on an UML component diagram for the team to review and see each addition interacts with the whole system, etc.

If we do that, then we can just give all the documents to a coding agent and say "go ahead and implement this" with a minimal amount of confidence. But in doing this, I bet we will realize the following:

    - the "effort" has never been about writing code itself. The code is just the material manifest of all the thought that went to think over a solution into the problems that the product is attempting to solve.

   - we will likely be better off by using code generation tools (i.e, UML-to-code) and a "weak" LLM (than can run locally) than by playing the token lottery at the Anthropic Casino.

I'd substitute "owner" for the team and in that sense the owner will not need to be human.

We're at this state where Claude is great at doing the "middle" part of work, but it's crap at gathering requirements and verification of what it has done. I also don't see people caring about these aspects of software development as shown in the article

That's so far been called software development.

All software developed by people suffers from this issue.

Where exactly is the novelty?

> The only way I see AI coding working in the long run is if we go back to a Waterfall/BDUF process and having actual engineering.

Nonsense. The problem is exactly the same.

With agents iterations are much faster, and this can mean things can get messier faster but can get in shape just as fast.

Ironically, agents improve the quality of the deliverable as well. Approaches such as spec-driven development do a far better job delivering features up to spec than manual coding by flesh and blood developers.

There's an awful lot of baseless scaremongering in your post. You make it sound like with AI assisted coding developers stopped paying any attention to quality.

And that’s pretty much where you are wrong. Take any long running open source project and you can see the craftsmanship that goes into it. It may not be perfect, but hacks are clearly marked as such.

The compounding speed. Your devs might reach a point where they have to rewrite and refactor, in a decade.

Your LLM, with its higher throughput, may put you in that game breaking situation next week.

I think that this is exactly why this scaremongering breaks down. If you believe the compounding speed is that greater, wouldn't you be compelled to accept that refactoring and cleaning things up is just as fast and effortless?

I mean, you have a tool that writes software for you following your commands. If you are that concerned with maintainability then what can possibly compell you to not invest any effort in it?

No. not at all. Imagine that each unit of work (a new PR for a feature, a bugfix) builds something that is 99% close to optimal and you can only get to bring it to 100% if you spend time to really review and rewrite the "not good" part. Also, for the sake of argument, let's just say that the overall quality of the system is geometric mean of the quality score of each unit of work. The only way to get an "ideal" system is by ensuring that work done on it follows the "ideal" architecture - for whatever "ideal" means for the developers/maintainers.

You are arguing that you are saving time because you only have to write the 1% that the AI got wrong, so you'd be getting a 100x speed up. My argument is that there is not so much time because if you want 100% quality, you will have to review 100% of the code. Understanding the produced code is the time-consuming part, not typing it out.

So, the only way to have these time savings by working with coding agents is if you accept that the code generated is good enough to not have careful review. But if you do that, then each unit of work that you tell yourself "not ideal but good enough. Ship it and we refactor later" ends up bringing the overall system quality. If you have 10 of these "99% good enough" PRs, and your overall system score is already at 90%. With 50 of these, the score dives down to 60%.

This is what OP and I are talking about "compounding" issues: unless we get to a point where generated code does not need review at all, your development speed will always be bottle-necked by the human in the loop. The only way to get speed benefits from the code generation is if we remove the human in the loop, but in doing so quality will drop faster than you can fix it.

I’m not saying that you can’t use AI to do it because I believe that with carefully controlled workflows and context management you can, but it’s not a simple prompt away, it’s requires guidance and understanding, and isn’t the speed demon that raw prompting is.

That's not really the point though. That presumes models are only useful if they are one-shot models. That is false.

I mean, what if your prompt successfully changes 20 source files and makes a mess in one? How much work did it saved?

And the elephant in the room is when models actually outperform whatever the prompter is able to deliver, and faster. That is somehow left out.

That’s not at all what I’m saying.

I’m saying that in my experience across multiple models, the follow up prompts don’t fix prior underlying issues. They usually patch on top instead, unless you give them significant and time consuming guidance.

I want them to be more useful outside of one-shot uses, but I find that they currently miss the mark.

That's not my experience at all, and I have been using models that are far from being cutting edge. Even in the cases where a model generates utter nonsense, a couple of clarifying questions is all it takes to get it back on track.

But that might be a factor of the project being worked on, and the extension of the changes being asked.

My preferred workflow these days is to pair program with an LLM until it gets close-ish and then manually touch it up. Without that, it just produces junk in different forms.

Doesn't matter how fast you can make the wrong thing.

I think computers are incredibly cheap compared to humans. These models and infrastructure to run them are going to only get more efficient in time. Right now we are still using (for the most part) entire hardware architectures mostly shoehorned from one purpose (graphics) into another. As purpose-built hardware becomes more prevalent and the SOTA starts to slow down I can't imagine a $100k hardware box not being able to handle a small team of developer's needs for many things.

I do think there will be a place for the top 20% of software engineers forever. But most people are not in that top 20%, and the quality when you get below average is not a linear progression. It will not be that difficult for AI generated code to beat the "bottom end" of the industry since tbh it's hard for me to tell the difference between LLM generated code and some of the shit I've seen over the years. I've ran across code written by folks who don't know what an array is more than once.

Most software is not built by MIT and Stanford grads making $500k/yr in the Valley. It's built by work-a-day programmers in the middle of nowhere making $80k/yr to keep some niche small business going with hyper-specific software that was first designed for Windows 95. Or stuff like making horribly designed Wordpress plugins. Or Shopify integrations. etc. etc.

I've also seen these small businesses totally held back by incompetent programmers, and despite their best efforts and huge amounts (for them!) of investment they can never seem to fix it. These types of enterprises are having AI run circles around their current engineering practices, even if it would make most FAANG engineers gasp in horror.

Either way it will certainly be interesting to watch! I just wish I was closer to retirement.

No, you can't. Adjusting prompts ensures absolutely nothing.

People said this about GPUs during the crypto mining craze and were wrong back then too. While I can’t speak for the entire industry I can say my personal experience follows any normal intuition over solid state electronics.

Some early failures in the bathtub curve, and then you start seeing fans, heat paste, and board capacitors fail far before you start seeing any chip failures at scale.

Sure you can abuse anything you want to burn it out, but I doubt that’s what’s happening inside these facilities.

If it gets zoned as parkland as part of a sale - great! You should be able to make that part of a sale contract. But if the governing body then votes to make it something else a decade later, that should simply be part of how things work.

Old people ossifying things to how they prefer via preventing future generations to freely operate is not how I want a society to run. If anything the older you get the less say in the future you should have.

It gets nuanced - but in general speaking terms this sort of thing should never be forever set in stone because someone alive 100 years ago decided as such via a private contract. Many other ways to go about setting aside areas for conservation.

Even conservation trusts make more sense to me. It’s still private, but they have an incentive to stay receptive to public comment and be a bit flexible. They might swap that 10 acres for another 100 acres somewhere else that creates a 1200 acre contiguous wilderness or what have you in order to stay relevant to contemporary needs while still staying true to the 250 year old mission.

I simply do not think you should be able to dictate (via private means) what happens to a property after you sell it. That’s for the next person who owns it to decide - in accordance with current local zoning and land use guidelines.

That seems to be what was used here. Then the trust sold it for some cash.