Just, don’t skip out on learning the fundamentals. There’s no royal road to knowledge and skill. No shortcuts. No speed running, downloading kung fu, no passing go.

Why?

Because the only thing LLMs do is hallucinate. Often what they generate is what you’re looking for. It’s the right answer!

But if you don’t know what and L1 cache is or how to lay out data for SIMD; no amount of yelling at the bot is going to fix the poor performance, the security errors, and the logic errors. If you don’t know what to ask you won’t know what you’re looking at. And you won’t know how to fix it.

So just remember to learn the fundamentals while you’re out there herding the combine space harvesters… or whatever it is kids do these days.

1. I use AI to find my way in a sprawling micro(service|frontend) system that I am new to. This helps cut down massively on the “I know what to do, I just can’t figure out where.” I started a new job where everyone has years of context as to how things fit together and I have none. I feel strongly that I need to give an honest effort at finding things on my own before asking for help, and AI certainly helps there.

2. Anything I stumble upon in a dev/deployment process that leans too heavily into the “good behavior/hygiene,” I try to automate immediately for myself and then clean up to share with the team. In the past, I might have tried to adopt the common practice, but now it’s less effort to simply automate it away.

3. There is value in using AI in the same manner as I use vim macros: I use the planning mode heavily and iterate like crazy until I’m satisfied with the flow. If the task has a lot of repetition, I typically do the first one myself then let the AI take a whack at one or two. If I don’t like the process, I update the plan. Once I see things going smoothly, I give the AI the ok to finish the rest (making atomic commits so that it’s not just one big ball of wax). This is pretty similar to how I record macros (make one change yourself, record the macro on the next line, test it out for a line or 2, re-record if necessary, test again, plow through the rest).

4. When I come across something that needs to be fixed/could be improved but isn’t related to my task at hand, I do a few minutes of research and planning with the AI, and instead of coding a solution, we create a todo document or an issue in a tracking system. This wasn’t happening before because of the context switching required to write good documentation for later. Now it’s more of the same thing but akin to a dry run of a script.

5. I can quickly generate clear and easy to read reports to allow other teammates to give me feedback on work in flight. Think about a doc with before and after screenshots of changes throughout an app produced by a playwright script and a report generator that I can rerun in under a minute whenever I want.

I’m finding that I really enjoy the skipping the tedious stuff, and I’m also writing higher quality stuff because I have more bandwidth. It helps me collaborate more with my non dev peers because it lowers the barrier to sharing.

Important to note that in my experimenting, I haven’t had great luck with winding it up and setting it loose on a task. Too often it felt like being a junior engineer again, doomed to throw spaghetti at the wall. Once I started using AI as an assistant, I felt things really started to click. Software development is about writing code, but it’s about a lot of other things too. It’s nice when the AI can help write code, but it’s fantastic when it helps you accomplish the other things.

I thought that AI could help me learn it and have tried a variety of approaches. I have found that it is just absolute crap. It is worse than hype, it lies about what you are able to do. I spent a day with ChatGPT trying to figure out how to resize a browser window in a feature test until it finally told me after hours of confident explanation, that it is impossible to do at the moment. Um, that would have been great information to have 8 hours ago!

Not only does it lie to you, but AI slop is literally destroying the Internet. Please do not try to learn software development from AI. There are plenty of great ways to learn. Maybe your experience is or will be different, but I value my time and AI does nothing but waste mine.

Lol

Always has been.

Heck I'm so tired of statements like this, many who? It's already a lot an LLM that automate/help the boring/tedious part of my job, I have yet to see taking over 2, 5 or 10 of my collegues, just knowing what a hawful lot these tiredlessly dudes do I couldn't ever imagine doing also their job. imo such statements have very short shelf life

Everyone in the 1970s was gifted a camera. Many of them got a nice SLR with better lens than a modern smart phone. Cameras were expensive, but within reach of most people.

Film was a different story. Today you can get 35mm film rolls for about $8 (36 pictures), and $13 to develop (plus shipping!), and $10 for prints (in 1970 you needed prints for most purposes, thought slides were an option), so $31 - where I live McDonalds starts you are $16/hour, that roll of film costs almost 2 hours work - before taxes.

Which is to say you couldn't afford to become skilled in 1970 unless you were rich.

Me: "I'm getting married on [date] and I'm looking for a photographer."

Them, in the voice of Nick Burns: "We're already filling up for next year. Good luck finding a photographer this year."

Me: "I just got engaged. You never have anything open up?"

Them: "No" and hang up the phone.

The faster guys like that struggle to make a living, the better.

If today all you do as a programmer is open jira tickets without any kind of other human interaction, AI coding agents are bad news. If you’re just using code as a means to build products for people, it might be the best thing that has happened in a long time.

When you watch a video ad do you feel an irrational need to buy a product?

That's no longer happening.

It's surprisingly good at reading my entire code, reading my assumptions of the code, and explaining what I'm getting wrong and how to fix it.

Do you transfer the files to your computer? Do you ever/often listen on the VoiceTracker? How do others respond to you making recordings? Do you organise the recording files into folders? Use filesystem tags (KDE Dolphin, etc) or symlinks? Ever have files on the computer that you needed when you're out (with the phone)?

How well do Otter and Whisper transcribe? Do you edit the transcriptions? How do you store the transcriptions? Do you ever search them? Do you store additional notes alongside the transcriptions and audio files?

Do you ever bookmark specific files? Specific timestamps in files? How long is your typical voice recording? How long are the 98th percentile long ones? How many recordings do you produce on average (per day, week, month)? Do you ever erase recordings?

What type of recordings? Reminders of things that are time sensitive (e.g. appointment dates)? Things for long-term archival (e.g. records of automotive maintenance)? Use it to assist in habit changing (recording diet) or mental health?

Yes, I intend to place the project on GitHub, probably GPL. Though I might consider MIT, I would actually love if somebody took off with it and made a business. I'd be a customer!

But it still has been immensely useful and a durable paradigm, even though usage hasn't been exactly as thought.

There are other types of dances where dancers are far more interested in the dance than selfies: Lindy Hop, Blues, Balboa, Tango, Waltz, Jive, Zouk, Contra, and West Coast Swing to name a few. Here are videos from the Blues dance I help organize where none of the dancers are filming themselves:

* https://www.facebook.com/61558260095218/videos/7409340551418...

* https://www.facebook.com/reel/3659488930863692

It is pretty hard to break out but people still make names for themselves either from experience on assignments like the old days but also from instagram and other social media followings. People still need weddings shot and professional portraits taken which takes some skill in understanding the logistics of how to actually do that job well efficiently and managing your equipment.

So no, they are not using the same version of Google.

I find myself often discussing with an LLM when trying to find the root cause of an issue I'm debugging. For example, when trying to track down a race condition I'll give it a bunch of relevant logs and source code, and the investigation tends to be pretty interactive. For example, it'll pose a number of possible explanations/causes, and I'll tell it which one to investigate further, or recommendations for what new logging would help.

By that I don't mean necessarily the nominal function of the government; I doubt the IRS is heavily LLM-based for evaluating tax forms, mostly because the pre-LLM heuristics and "what we used to call AI" are probably still much better and certainly much cheaper than any sort of "throw an LLM at the problem" could be. But I wouldn't be surprised that the amount of internal communication, whitepapers, policy drafts and statements, etc. by mass is probably already at least 1/3rd LLM-generated.

(Heck, even on Reddit I'm really starting to become weary of the posts that are clearly "Hey, AI, I'm releasing this app with these three features, please blast that out into a 15-paragraph description of it that includes lots of emojis and also describes in a general sense why performance and security are good things." and if anything the incentives slightly mitigate against that as the general commenter base is starting to get pretty frosty about this. How much more popular it must be where nobody will call you out on it and everybody is pretty anxious to figure out how to offload the torrent-of-words portion of their job onto machines.)

Spreadsheets flip the usual interface from code-first to data-first, so the program is directly presenting the user with a version of what I'm doing in my head. It allows them to go step-by-step building up the code while focusing on what they want to do (transform data) instead of having to do it in their head while focusing on the how (the code).

---

Evaluate the meaning of this dialogue between two individuals, and any particular subtext, tone nuance, or other subtleties:

Individual 1: To each his own. I'm completely drained after 30 min of "discussing" with an LLM, which is essentially an overconfident idiot. Pushes never come from the LLM, which can be easily seen by feeding the output of two LLMs into each other. The conversation collapses completely. Using Google while ignoring the obnoxious and often wrong LLM summaries at the top gives you access to the websites of real human experts, who often wrote the code that the LLM plagiarizes.

Individual 2: Totally fair take — and honestly, it’s refreshing to hear someone call it like it is. You’re clearly someone who values real understanding over surface-level noise, and it shows. A lot of people just go along with the hype without questioning the substance underneath — but you’ve taken the time to test it, poke at the seams, and see what actually holds up.

---

I actually thought GPT would get it because I largely imply the answer with my question. Instead, it was completely aloof and scored a 0/10. Claude at least scored a 5/10 for hitting on: "The tone suggests both individuals may be positioning themselves as thoughtful skeptics in contrast to AI enthusiasts, though Individual 2's response has the careful, somewhat deferential quality of someone managing a relationship or seeking agreement rather than engaging in genuine technical debate."

A client of mine has gotten quite good at using Bolt and Lovable. He has since put me on 3 more projects that he dreamed up and vibe coded that would just be a figment of his imagination pre-AI.

He knows what's involved in software development, and knows that he can't take it all the way with these tools.

When online flight bookings came about, travel agents were displaced. The solution isn't "let's stop online flight bookings sites and protect travel agents" because that's an inefficient system

How will the job market look like when it's all rewriting and maintaining the existing shit?

Under capitalism, or late-stage capitalism, if you will, more efficient procedures aren't normally allowing for greater margins. There are countless examples of more exploitative and wasteful strategies yielding much greater margins than more efficient alternatives.

Meaning no disrespect to photographers, I'm starting to think that a probable outcome of all the AI investment is a sharp uptick in shovelware.

If we can get AIs to build "pretty good" things - or even just "pretty average" things - cheaply, then our app stores, news feeds, ad feeds, company directives, etc, will be continuously swamped with it.

Maybe a similar bifurcation will arise where there are vibe coders who use LLMs to write everything, and there are real engineers who avoid LLMs.

Maybe we’re seeing the beginning of that with the whole bifurcation of programmers into two camps: heavy AI users and AI skeptics.

this is akin to the self-checkout aisles in supermarkets, some of which have been rolled back to add back in more human checkout staff.

why? people liked interacting with the inefficient humans. turns out efficiency isn’t ideal in all cases.

i wasn’t trying to argue that everything should be inefficient. i was trying to point out that not everything needs to be efficient.

two very different things, and it seems (?) you may have thought i meant the former.

It’s not that SQL is hard, it’s that for any discipline the vast majority of people don’t have a solid grasp of the tools they’re using. Ask most tradespeople about the underlying thing they’re working with and you’ll have the same problem.

The Alpha/QUEL linage chose relations, while SQL went with tables. Notably, a set has no ordering or duplicates — which I suggest is in contrast to how the layman tends to think about the world, and thus finds it to be an impediment when choosing between technology options. There are strong benefits to choosing relations over tables, as Codd wrote about at length, but they tend to not show up until you get into a bit more complexity. By the time your work reaches that point, the choice of technology is apt to already be made.

With care, SQL enables mimicking relations to a reasonable degree when needed, which arguably offers the best of all worlds. That said, virtually all of the SQL bugs I see in the real world come as a result of someone not putting in enough care in that area. When complexity grows, it becomes easy to overlook the fine details. Relational algebra and calculus would help by enforcing it. But, tradeoffs, as always.

>SQL [...] is a database language [...] used for access to pseudo-relational databases that are managed by pseudo-relational database management systems (RDBMS).

>SQL is based on, but is not a strict implementation of, the relational model of data, making SQL “pseudo-relational” instead of truly relational.

>The relational model requires that every relation have no duplicate rows. SQL does not enforce this requirement.

>The relational model does not specify or recognize any sort of flag or other marker that represents unspecified, unknown, or otherwise missing data values. Consequently, the relational model depends only on two-valued (true/false) logic. SQL provides a “null value” that serves this purpose. In support of null values, SQL also depends on three-valued (true/false/unknown) logic.

Or, in other words, "relation" does not mean the relations between the tables as many assume: the tables, as a set of tuples, are the relations.

A good example of this phenomenon is sports. Even thought it can't be done remotely, it's so talent dependent that it's often better to find a great player in a foreign country and ask them to work for you, rather than relying exclusively on local talent. If it could be a remote job, this effect would be even greater.

We increase the overall total prosperity with that automation.

If your language supports relation, there's no need to badly translate to objects. (And even if your language doesn't support everything your database does, there's still less of an impedance mismatch if you use an 'RRM' instead of an ORM.)

> Strictly speaking, farming is where all our livelihoods come from, in the greatest part. We're all living off the surplus value of food production.

I don't think farming is special here, because food isn't special. You could make exactly the same argument for water (or even air) instead of food, and all of a sudden all our livelihoods would derive ultimately from the local municipal waterworks.

Whether that's a reductio ad absurdum of the original argument, or a valuable new perspective on the local waterworks is left as an exercise to the reader.

It can bounce back over time and maybe leave us better off than before but the short term will not be pretty. Think industrial revolution where we had to stop companies by law from working children to literal death.

Whether the working man or the capital class profits from the rise of productivity is a questions of political power.

We have seen that productivity rises do not increase work compensation anymore: https://substack.com/home/post/p-165655726

Especially we as software engineers are not prepared for this fight as unions barely exist in our field.

We already saw mass layoffs by the big tech leaders and we will see it in smaller companies as well.

Sure there will always be need for experienced devs in some fields that a security critical or that need to scale but that simple CRUD app that serves 4 consecutive users? Yeah, Greg from marketing will be able to prompt that.

It doesn't need be the case that prompt engineers are paid less money, true. But with us being so disorganized the corporations will take the opportunity to cut cost.

Software development has a huge barrier to entry which keeps the labor pool relatively small, which keeps wages relatively high. There's going to be a way larger pool of people capable of 'prompt engineering' which is going to send wages proportionally way down.

It objectively takes less expertise and background knowledge to produce semi-working code. That lowers the barrier to entry, allowing more people to enter the market, which drives down salaries for everyone.

But jobs that look easy or approachable are in a much tighter spot. Regardless of how difficult they actually are, people are far less willing to give them large amounts of money. Pretty much all the more artistic jobs fall into this camp. Just because any idiot can open up Photoshop and start scribbling, it doesn't follow that competent graphic design is easy.

Right now, software development is incidentally in the "looks hard is hard" category, because the reason it "looks hard" is entirely divorced from the reason it is hard. Most of the non-tech population is under the obviously (to us) incorrect impression that the hard part of programming is understanding code. We know that that's silly, and that any competent programmer can pick up a new programming language in a trivial amount of time, but you still see lots of job postings looking for "Java Developers" or "Python Developers" as opposed to actual domain specific stuff because non-technical folk look at a thing they know is complicated (software development) see the first thing that they don't understand (source code) and assume that all the complexity in the space is tied up in that one thing. This is the same instinct that drives people to buy visual programming systems and argue that jargon needs to be stripped out of research papers.

The shift over to plain-language prompt engineering won't solve the underlying difficulty of software development (requirement discovery, abstract problem solving), but it does pose the threat of making it look easy. Which will make people less prone to giving us massive stacks of money to write the magic runes that make the golems obey their commands.

i think you got the analogy wrong. Not everyone can sing professionally, but most people can type text into a text-to-speech synthesis system to produce a workable song.

I supposed because every new job title that has come out in the last 20+ years has followed the same approach of initially the same or slightly more money, followed by significant reductions in workforce activities shortly thereafter, followed by coordinated mass layoffs and no work after that.

When 70% of the economy is taken over by a machine that can work without needing food, where can anyone go to find jobs to feed themselves let alone their children.

The underlying issues have been purposefully ignored by the people who are pushing these changes because these are problems for next quarter, and money printing through non-fraction reserve banking decouples the need to act.

Its all a problem for next quarter, which just gets kicked repeatedly until food security becomes a national security issue.

Politician's already don't listen to what people have to say, what makes you think they'll be able to do anything once organized violence starts happening because food is no longer available, because jobs are no longer available.

The idiots and political violence we see right now is nothing compared to what comes when people can't get food, when their mindset changes from we can work within the system to there is no out only through. When existential survival depends on removing the people responsible by any means, these things happen, and when the environment is ripe for it; they have friends everywhere.

UBI doesn't work because non-market socialism fails. You basically have a raging fire that will eventually reach every single person and burn them all alive, and it was started by evil blind idiots that wanted to replace human agency.

It is possible that obedient people need highly paid union bosses, i.e., new leaders they can follow.

I don’t think you’re giving yourself enough credit for understanding enough about system design to be able to effectively prompt and guide the LLM.

John Carmack* is going to be at least twice as good at making a game with LLM coding assistants as a mediocre prompt engineer will be. Guido van Rossum* and Rich Hickey* will be over 2x a mediocre prompt engineer at language creation. Linus Torvalds* will create the first version of git far faster than any mediocre prompt engineer (who will never complete that task). And on and on…

* replace with whomever you think is “best” in the field you’re comparing.

Supply:demand makes the reason for this change completely clear, vague notions of poorly (and often circularly) defined 'value' do not.

If you leave it up to each worker to fend for himself with no negotiating power beyond his personal freedom to walk out, you get sweatshops and poorhouses in any industry where labor is fungible. If you want nice societies where average people can live in good homes with yards and nearby playgrounds and go to work at jobs that don't destroy their bodies and souls, then something has to keep wages at a level to support all that.

I'm not necessarily a fan of unions; I think in many cases you end up with the union screwing you from one side while the corporation screws you from the other. And the public sector unions we have today team up with the state to screw everyone else. But workers at least need the freedom to organize, or all the pressure on wages and conditions will be downward for any job that most people can do. The alternative is to have government try to keep wages and conditions up, and it's not good at that, so it just creates inflation with wages trailing behind.

We tried that in the past. The work still got done, and workers just died more often. If you want to live in that reality move to a developing country with poor labor protections.