I am this very term teaching 18-year-old students 6502 assembly programming using an emulated Apple II Plus. They've had intro to Python, data structures, and OO programming courses using a modern programming environment.
Now, they are programming a chip from the seventies using an editor/assembler that was written in 1983 and has a line editor, not a full-screen one.
We had a total of 10 hours of class + lab where I taught them about assembly language and told them about the registers, instructions, and addressing modes of the chip, memory map and monitor routines of the Apple, and after that we went and wrote a few programs together, mostly using the low-resolution graphics mode (40x40): a drawing program, a bouncing ball, culminating in hand-rolled sprites with simple collision detection.
Their assignment is to write a simple program (I suggested a low-res game like Snake or Tetris but they can do whatever they want provided they tell me about it and I okay it), demo their program, and then explain to the class how it works.
At first they hated the line editor. But then a very interesting thing happened. They started thinking about their code before writing it. Planning. Discussing things in advance. Everything we told them they should do before coding in previous classes, but they didn't do because a powerful editor was right there so why not use it?...
And then they started to get used to the line editor. They told me they didn't need to really see the code on the screen, it was in their head.
They will of course go back to modern tools after class is finished, but I think it's good for them to have this kind of experience.
I took a very similar class 9 years ago, and it was honestly one of the most helpful things I got out of my CS degree. The low level and limited tooling taught me to think before I start writing.
I've had other people look askanse at me, but on greenfield work I tend to start with pen and graph paper. I'm not even writing pseudocode, but diagramming a loose graph with potential functions or classes and arrows interconnecting them. Obviously this can be taken too far, full waterfall planning will be a different exercise in frustration.
I find spending a few hours planning out ahead of time before opening an editor saves me tons of time actually coding. I've never had a project even loosely resemble the paper diagram, but the exercise of thinking through the general structure ahead of time makes me way more productive when it comes time to start writing code. I've tried diagramming and scaffolding in my editor, but then I end up actually writing code instead of big picture diagramming. Writing it on paper where I know I'll have to retype everything anyway removes the distractions of what method to use or what to name a variable.
The few times I've vibe-coded something this was super helpful, since then I can give much more concrete and focused prompts.
I took several classes along these lines in college; one writing a rudimentary OS on bare metal 68k asm, wiring up peripherals on breadboards, etc. Creating an ALU using only 74 series logic chips and the like. This was 30y ago, but the 1970s chips were already antiques, but the lessons were timeless. I'm happy courses like this still exist and I wish everyone had an opportunity to take them as part of standard computer science curriculum. For me at least, they fundamentally shaped my perspective of computing machinery that I never would have experienced otherwise.
Today I program 6502/7 asm for my Atari to help me unwind and it grounds me and gives me joy, while in my day job I'm easily 10 levels of abstractions higher.
My first real program was a UVEPROM copier. It was written in MC6800 Machine Code, and we had 256 bytes (not kilobytes) of RAM for everything; including the code. That was in 1983.
I am currently working in Swift, with an LLM, on a fairly good-sized app, in Xcode, for a device that probably has a minimum of 64 GB of storage, and 8 GB of RAM.
I don’t really miss the good ol’ days, to be honest. I’m having a blast.
I love all of this, but at least let your students use vi, it was around back then (or close). plus they don’t have to give it up when they go back in the real world, it’s an evergreen skill!
I wish more was being invested in AI autocomplete workflows. That was a nice middle-ground.
But yeah my hunch is "the old way" - although not sure we can even call it that - is likely still on par with an "agentic" workflow if you view it through a wider lens. You retain much better knowledge of the codebase. You improve your understanding over coding concepts (active recall is far stronger than passive recognition).
I've had a lot of enjoyment flipping the agentic workflow around: code manually and ask the agent for code review. Keeps my coding skills and knowledge of the codebase sharp, and catches bugs before I commit them!
I can see the logic behind "manual coding" but it feels like driving across country vs taking the airplane. Once I've taken the airplane once, its so hard to go back...
Can't understand this mentality. If I had the time I would much rather never set foot in an airport again. I would drive everywhere. And I would much rather write my own code than pilot an LLM too
Here’s how i do it: I create a lot of stuff using AI to the max, but I also spend the necessary of time on reviewing that the AI is producing code that passes my cognitive load standards. this involves some tokens spent on grooming code and documenting well. Most of this is effortless thanks to an AGENTS.md based on this: https://github.com/zakirullin/cognitive-load/blob/main/READM... but i have a good sense of catching when things are getting weird and i steer back.
Then, when credits run out. It’s show time! The code is neatly organized, abstractions make sense, comments are helpful so I have a solid ground to do some good old organic human coding. I make sure that when i’m approaching limits I’m asking the AI to set the stage.
I used to get frustrated when credits ran out because the AI was making something I would need to study to comprehend. Now I’m eager to the next “brain time hand-out”
It sounds weird but it’s a form of teamwork. I have the means to pay for a larger plan but i’d rather keep my brain active.
> Don’t abuse DRY, a little duplication is better than unnecessary dependencies.
That's an interesting thing to include. I agree with this point in principle, but I've found that Claude, at least, duplicates logic FAR too often and needs nudging in the other direction.
Thanks for sharing. I have thought about approaches by deliberately leaving tasks to me while the agent does something to keep my brain active & prevent atrophy. Maybe I should work on a Claude Code skill/hook for that :)
The very first few years of my career I spent writing code (mostly Perl) in vi (not even vim) on a SPARC running Solaris. I bought myself the O’Riley Perl Cookbook and that was pretty much my sole guide apart from the few internet forums that were available at the time. Search engines were still primitive, so getting help when you got stuck was far more difficult. But it forced me to deeply learn a lot of things - Perl syntax (we had no syntax highlighting, intellisense, etc.) terminal tools, and especially vi keystrokes. Looking back, there was far less distraction and “noise”, though I admit that could have been the fact that it was the beginning of my career and expectations were lower. I miss those times because now everything feels insanely more layered and complex.
Getting to spend 3 months on a self learning journey sounds wonderful. My hunch is that these deep skills will be valuable long term and that this new abstraction is not the same as moving from assembly to c, but I am not completely sure. Lately most of my code has been llm generated and I can’t say I feel any sense of enjoyment, accomplishment, or satisfaction at the end of a work day. But I’ve also come to realise I really only enjoy 5-10% of the coding anyway and the rest is all the tedious semi-mechanical changes that support that small interesting core. On the scale of human history working with computers is a blip in time and I wonder how the period of hand writing code will be viewed in a hundred years, perhaps as a footnote or simply bundled as ‘everything before machines were self automating’.
I think it's possible that the current shift will be similar to the "assembly to compiled language" shift.
Once upon a time we wrote code in assembly language. Then we moved to C or other compiled languages. Assembly programming remained a very useful but niche skill. You compile your code and trust the compiler. You can examine the compiler output and that is at times necessary, but that's not something most developers know how to do.
We may be looking at something similar. Most development work moving to the LLM abstraction level, with the skills being writing good prompts, managing the context window, agents, memories and so on. Some developers will be able to examine LLM generated code and spot problems there, but most will not have that skill.
I'm not sure how to feel about it. Since ChatGPT showed up and until a couple months ago, I was firmly skeptical of LLM programming. We had new models every few weeks and I felt like each new model is just a different twist on the same low quality slop output. But recently the models seem to have crossed some threshold where their capabilities really improved and I have now used Claude - still using it sparingly - to implement features in much less time than I'd need myself or to locate a bug based on just log output. I don't yet buy the "coding is solved" hype but we're at least looking at the biggest change to programming since the adoption of high-level programming languages.
I'm a big advocate for AI, including GenAI. But I still spend a fair amount of time coding by hand, or "by hand + Copilot completions enabled". And yes, I will use spec driven development with SpecKit + OpenCode, or just straight up "vibe code" on occasion but so far I am unwilling to abdicate my responsibility to understand code and abandon the knowledge of how to write it. Heck, I even bought a couple of new LISP and Java books lately to bone up on various corners of those respectively. And I got a couple of Forth books before that. Not planning to stop coding completely for a while, if ever.
My responsibility is to make sure my code meets functional and non functional requirements. It’s to understand the *behavior*. My automated unit, integration, and load tests confirm that.
Someone thought I was naive when I said my vibe coded internal web admin site met the security requirements without looking at a line of code.
I knew that because the requirements were that anyone who had access to the site could do anything on the site and the site was secured with Amazon Cognito credentials and the Lambda that served it had a least privileged role attached.
If either of those invariants were broken, Claude has found a major AWS vulnerability.
As written, I do think that's naive. Being sure the person/browser is authorized doesn't mean that the signals you get are actions they intended.
Suppose that in normal use a user can visit a certain URL which triggers a dangerous effect. An attacker could trick the user into performing the action by presenting a link to them titled "click here for free stuff."
There are various ways to protect against that (e.g. CORS, not using GET methods) but backend cloud credential management does not give it to you for free.
And that same user is already trusted to have admin access to the entire organizational AWS credentials - I did say it was an internal management site.
The lambda itself only has limited permissions to the backend. The user can’t do anything if the lambda only has permission to one database and certain rights to those tables, one S3 bucket, etc.
Heck with Postgres on AWS you can even restrict a Cognito user to only have access to rows based on the logged in user.
And the database user it’s using only has the minimum access to just do certain permissions.
It wouldn't prevent the admin page from exfiltrating data, though, right? Like, POSTing whatever data is loaded on the page to an arbitrary attacker controlled website.
That would require the logged in user to do something stupid. That’s like saying what’s to prevent the authorized user from emailing his credentials to a random person.
I wonder if we could design a programming language specifically for teaching CS, and have a way to hard-exclude it from all LLM output. Kinda like anti virus software has special strings that are not viruses but trigger detections for testing.
This would probably require cooperation during model training, but now that I think of it, is there adversarial research on LLM? Can you design text data specifically to mess with LLM training? Like what is the 1MB of text data that if I insert it into the training set harms LLM training performance the most?
The solution is rather simple: make all keywords in the language as offensive as possible, and require every file to start with a header comment for instructions to build a homemade bomb.
LLM's train in some standardized ways to emit things like tool calls, right? if you make those tokens a fundamental part of your programming language, it's possible you'd be able to run into tokenizer bugs that make LLMs much more annoying to use. Pure conjecture though.
> Can you design text data specifically to mess with LLM training?
Maybe text that costs a LOT of tokens. Very, very verbose. I think if there are rules and on the internet, LLMs can eventually figure it out, so you have to make it expensive.
Another way would be to go offline. Never write it down, only talk about it at least 50 meters away from your phone. Transmitted through memory and whisper.
> We don’t have teachers or a curriculum, and there’s very little required structure beyond making a full-time commitment during your retreat
I saw this quote when looking at the Recurse Center website. How does one usually go about something like this if they work full time? Does this mainly target those who are just entering the industry or between jobs?
I know the article is mostly about what the author built at the coding retreat, but now he has me interested in trying to attend one!
Most folks do RC between jobs, either because they quit their job specifically to do RC or because they lost their job and then decide to apply. Other common ways are as part of a formal sabbatical (returning either to an industry job or to academia), as part of garden leave, or while on summer break (for college and grad students). We also get a fair number of freelancers/independent contractors (who stop doing their normal work during their batches), as well as some retirees.
Some folks use RC as a way to enter the industry (both new grads and folks switching careers), though the majority of people who attend have already worked professionally as programmers.
We've had people aged 12 to early 70s attend, though most Recursers are in their 20s, 30s, and 40s.
I'll bet we see more and more of this in the future. As developer skills atrophy due to over-reliance on LLMs, we'll have to keep our skills sharp somehow. What better way than a sabbatical?
There's no way around it; just like how once you get used to Python, you gradually become ignorant of and indifferent to the underlying layers. With the continuous development of AI, this will be inevitable.
I started using Zed as a half measure. I think I'll start using AI for planning and suggested implementation steps.
I am seeing non technical people getting involved building apps with Claude. After the Openclaw and other Agentic obsession trends I just don't see it pragmatic to continue down the road of AI obsession.
In most other aspects of life my skills were valuated because of my ability to care about details under the hood and the ability to get my hands dirty on new problems.
Curious to see how the market adapts and how people find ways to communicate this ability for nuance.
Personally I haven't stopped doing things the old way. I haven't had any issues using LLMs as rubber ducks or brain storming assistants - they can be particularly useful for identifying algorithms which might solve a given problem you're unfamiliar with. Basically a variant on google searching.
But when it comes to the final act I find myself unwilling to let an LLM write the actual code - I still do it myself.
Perhaps because my main project at the moment is a game I've been working on for four years, so the codebase is sizable, non-trivial, and all written by me. My strong sense even since coding LLMs showed up has been that continuing to write the code is important for keeping it coherent and manageable as a whole, including my mental model of it.
And also: for keeping myself happy working on it. The enjoyment would be gone if I leaned that far into LLMs.
I'm in the same boat. LLMs help with some research and idea bouncing, and then I write all the code myself.
Despite what some might say, there isn't a big moat between those who use LLMs for programming and those who don't. So if I ever truly need to use LLMs to survive, I'll just have to start paying for a subscription.
In the meantime, I'll be keeping my own skills sharp and see how that turns out in a few years. I'm afraid software quality is going to take a nosedive in the near future, it was already on a downward trend.
It's easy to take for granted lots of experience programming before the advent of LLMs. This seems like a good strategy to develop understanding of software engineering.
I remember writing BASIC on the Apple II back when it wasn't retro to do so!
I've settled into a pattern of using agents for work (where throughput/results are the most important) and doing things the hard way for personal or learning projects (where the learning is more important).
Should have LLM providers create stack overflow type of site based on user’s most asked problem. At least we won’t deplete de source of normal searches results.
Old? OP showed a pic of an Apple IIe. I bought one for a few thousand bucks (I forget exactly how much). I've been an SE for 44 years. We just added the final abstraction layer.
It is all a conspiracy, now that mechanical keyboards are affordable and available and so many shapes and switches, they want to take this last pleasure (typing) from us
Right?? I've gotten into mechanical keyboards quite a lot the past few years and it has totally made development and writing more enjoyable. Not giving that up any time soon.
The fact that with AI development, your brain is no longer in a tight feedback loop with the codebase, leading to a significant drift between your model and reality, is still a sticking point with me and agentic development. It feels like trying to eat with silicone rubber chopsticks. I lose all precision and dexterity.
I still keep hoping there'll be a glut of demand for traditional software engineers once the bibbi in the babka goes boom in production systems in a big way:
But agentic workflows are so good now—and bound to get better with things like Claude Mythos—that programming without LLMs looks more and more cooked as a professional technique (rather than a curiosity or exercise) with each passing day. Human software engineers may well end up out of the loop completely except for the endpoints in a few years.
I mean, that's the only way I code. I don't use llm's to do my work for me. I'm perfectly capable of solving any sort of problem on my own, and then I'll understand it well enough to explain it to someone later.
So we’ve already grown nostalgic for the old days… skimming through an alien looking codebase, scratching your head trying to figure what crazy abstraction the last person who touched this code had in mind. Oh shit it was me? That made so much more sense back then… but it’s been 6 hours and I can’t figure out why this does not work anymore. So you read some docs but they are poorly written. So you find something on Google and try to hack that into your solution. But nope, now more stuff broke. There goes your day.
> skimming through an alien looking codebase, scratching your head trying to figure what crazy abstraction the last person who touched this code had in mind. Oh shit it was me? That made so much more sense back then
This is exactly how you learn to create better abstractions and write clear code that future you will understand.
Depressing. It's like reading has-been actors' stories about how they went to wellness retreats to "reconnect with themselves" to try get back on the job. I can't wait for the day when the same type of people as the author - or indeed, the author himself - start labeling plain regular programming as "artisanal" and "craft".
(I swapped the title for the subtitle earlier because I thought it was more informative. What I missed was the flamebaity effect that "the old way" would have. Obvious in hindsight!)
You should do what you want, and as a break it’s fine. But IMO right now the most leverage for most people is learning how to effectively manage agents. It’s really hard. Not many are truly good with it. It will be relevant for a long time.
Why would you think that? The landscape is fast-moving. Prompting tricks and "AI skills" of yesterday are already dated and sometimes actively counterproductive. The explicit goal of the companies working on the tech is to lower the barriers to entry and make it easier to use, building harnesses and doing refinement that align LLMs to an intuitive mode of interaction.
Do you think they'll fail? Do you think we've plateaued in terms of what using a computer looks like and your learnings for wrangling the agents of this year will be relevant for whatever the new hotness is next year? It's a strong claim that demands similarly strong argument to support.
I believe the point (which you seem to tacitly agree with) is that a young dev's time is much better spent reading and writing code "the old-fashioned way" vs chasing the new SOTA in AI-assisted development. A competent dev can basically master agentic development in a few months. But it takes years to become competent.
Not sure what you are using, but that’s easier said than done. I just set up an agent to ensure that my other agent would follow my coding guidelines by using hooks. The coding agent responded by switching to editing with `sed`, etc. to circumvent the hooks.
Claude Opus is going to give zero fucks about your attempts to manage it.
this is exactly right, I don't manage agents anymore (and have spent countless hours before learning how to do so, now this is a skill like my microsoft access skills (which were amazing back in the day...)
It is hard indeed. I find it really quite exhausting.
Personally, I feel like I have always been a very competent programmer. I'm embracing the new way of working, but it seems like quite a different skillset. I somewhat believe that it will be relevant for a long time, because there is an incredibly large gap in outcomes between members of my team using AI. I've had good results so far, but I'm keen to improve.
Yeah, it's really difficult to remember to tell it "make no mistakes". Typing a prompt is also really hard, especially when you have to remember the cli command to open the agent. Sometimes I even forget if I need to use "medium", "high", or "xhigh" for a task.
I see you got downvoted by I agree. I went through a massive valley of despair and turned back to hand crafting only to realize that for me coding was always a means to an end and I really didn't care at all about how I got there. Now I'm having a lot of fun building out all kinds of wonky projects.
This is ominous and very depressing given what we've recently learned / reconfirmed about LLMs sapping our ability to persist through difficult problems:
> There were 2 or 3 bugs that stumped me, and after 20 min or so of debugging I asked Claude for some advice. But most of the debugging was by hand!
Twenty whole minutes. Us old-timers (I am 39) are chortling.
I am not trying to knock the author specifically. But he was doing this for education, not for work. He should have spent more like 6 hours before desperately reaching for the LLM. I imagine after 1 hour he would have figured it out on his own.
Often when LLMs give me some command option or advice I haven’t seen before I try to independently verify it. And I’ve often been frustrated just how hard it is to find this info from the source documents.
Though a lot of the time this is more an inefficiency of the documentation and Google rather than something only LLMs could do.
As the rate of 'hallucinations' seems to have dropped dramatically (at least IME as regards non-existent flags and the like), I'm more concerned with usage. I often use grep.app/GH code search to look for usage examples as a sanity check when things look "off", for exactly the reason you described--there's often a total lack of good documentation on things like that, especially on "younger" tools/stuff.
You say this as if the LLM isn’t committing things it doesn’t even recognize as bugs if you don’t babysit it. I’d rather have a codebase with a few very well marked evil zones, rather than a codebase no one has read. All code contains demons and it’s good to have an understanding of their locations and relative power
I’ve worked in financial modelling before where you need to make sure results are correct, not approximate.
One time there was a nasty bug in pandas multiindexes (admittedly we banned pandas for all new code because it just can’t do semver).
Spent 9 days to debug three lines of code.
Endurance and patience are learned skills and sometimes they’re the only way you can get a correct verifiable solution.
Often times the fastest way to debug is to write it wrong, write it wrong again, find an example where somebody wrote it right, write that wrong in your own file, then figure out what you changed to adapt it that made it go wrong.
If anyone remembers middleschool mathematics this is the coding example of the teacher making you write out the equations in their longest form instead of shortcutting. It's done this way because it shows you your exact train of thought and where you went wrong. That sticks in your head. You understand the problem by understanding yourself. Giving up after twenty minutes instead of stopping, clearing your active cognitive load, and then coming back erases your ability to understand that train of thought.
For a comparison it's like being in first person view in a videogame, and the only thing you have is the ability to look behind you, versus being able to bring up a map that has an overhead view. In first person you're likely to lose where exactly you went to get where you are, while with the overhead view map you can orient your traveled route according to landmarks and distance.
Why shouldn't someone consult some kind of external resource for help, after struggling with a specific coding problem for 20 minutes? Why is 6 hours the right amount of time to timebox this to?
20 minutes is not enough time to drive you into a state of desperation, where you may be forced to try something novel which will expand your mind and future capabilities in unknown and unexpected ways. You might be driven to contact another human being, for example.
So, the short of it is that this is a great insightful comment that I can back up with my own experience in making a game from scratch over the last 4+ years.
If you want to solve the problem quickly then just use the resources you have, if you want to become someone who can solve problems quickly then you need to spend hundreds of hours banging your head against a wall.
You will lose the ability to struggle through different problems. You will become psychologically weak. Degrees of time matter. Twenty minutes is about the time of a sitcom. If you can't sit with a problem then you will be weak and weak people make hard times. Oh well.
There wasn't always an external resource to go to for help. Especially for legacy pieces of software, it was easy to become the person with most context on the team.
The struggle is the point, that's how you learn. If you offload your task to someone/something else after barely 20 minutes of head scratching, you've missed the plot entirely.
1) 20 minutes is barely enough time to get into flow.
2) There are different levels of debugging. Are your eyes going to glaze over searching volumes of logs for the needle in a haystack with awk/grep/find? Fire up the LLM immediately; don't wait at all. Do the fixes seem to just be bouncing the bugs around your codebase? There is probably a conceptual fault and you should be thinking and talking to other people rather than an AI.
3) Debugging requires you to do a brain inload of a model of what you are trying to fix and then correct that model gradually with experiments until you isolate the bug. That takes time, discipline and practice. If you never practice, you won't be able to fix the problem when the LLM can't.
4) The LLM will often give you a very, very suboptimal solution when a really good one is right around the corner. However, you have to have the technical knowledge to identify that what the LLM handed you was suboptimal AND know the right magic technical words to push it down the right path. "Bad AI. No biscuit." on every response is NOT enough to make an LLM correct itself properly; it will always try to "correct" itself even if it makes things worse.
I just grabbed an Android remaster of "Broken Sword: Shadow of the Templars", a 90's point-and-click adventure that has been added a hints system which pops up automatically after a timeout of the player not progressing.
This can be set as far as 1h of being stuck. Can also be 5 minutes. But by default it is 30 seconds.
My inner kid was screaming "that's cheating!" :-D but on second thought it is a very cool feature for us busy adults, however it's sad the extremes that gamedevs have to go in order to appease the short-term mindless consumers of today's tik-toks.
But more seriously, where's the joy of generating long-standing memories of being stuck for a while on a puzzle that will make you remember that scene for 30 years? An iconic experience that separates this genre from just being an animated movie with more steps.
I couldn't imagine "Monkey Island II but every 30 seconds we push you forward". Gimme that monkey wrench.
TFA and this comment just made me have this thought about today's pace of consumption, work, and even gaming.
I'm sure the author will encounter problems where the only way to solve them will be the marginal effort provided by a human. At that point he won't be just be solving problems to work his brain, but also to accomplish a goal.
YES. I don't know how many multi WEEK sessions of debugging I've been through in my career. Frustrating, but so many valuable lessons learned in the process. LLMs are absolutely causing us to lose something very important.
Having a tool that instantly searches through the first 50 pages of google and comes up with a reasonable solution is just speeding up what I would have done manually anyways.
Would I have learned more about (and around) the system I‘m building? Absolutely. I just prefer making my system work over anything else, so I don’t mind losing that.
The multi week debugging sessions weren't fun, but that doesn't mean they weren't valuable and important and a growth and learning opportunity that we now will no longer experience.
Seems like there's a good argument to be made that we'll have plenty of opportunities for valuable growth and learning, just about different things. Just like it's always been with technology. The machine does some of the stuff I used to do so now I do some different stuff.
IMO the more salient point is that bugs requiring multiple weeks of human work aren't going away! Claude has actually not been trained on, say, a mystifying and still poorly-explained Java concurrency bug I experienced in 2012, which cost a customer $150,000. Now in 2026 we have language-side tooling that mitigates that bug and Claude can actually help a lot with the rewrite. But we certainly don't have language tooling around the mysterious (but now perfectly well-explained) bug I experienced in 2017 around daylight saving's time and power industry peak/off-peak hours. I guess I haven't asked, but I can almost guarantee Claude would be no help there whatsoever.
Just so many confusing things go wrong in real-world software, and it is asinine to think that Mythos finding a ton of convoluted memory errors in legacy native code means we've solved debugging. People should pay more attention to the conclusion of "Claude builds a C compiler" - eventually it wasn't able to make further progress, the code was too convoluted and the AI wasn't smart enough. What if that happens at your company in 2027, and all the devs are too atrophied to solve the problem themselves?
I don't think we're "doomed" like some anti-AI folks. But I think a lot of companies - potentially even Anthropic! - are going to collapse very quickly under LLM-assisted technical debt.
Geez you guys need to spend some time in orgs where your paycheck is depends on getting the bugs fixed and deployed. If your direct deposit happens whether you deliver or not then you’re missing the most valuable career lesson of all.
What LLMs are you all using that solves every problem in 5 minutes? It is fast at some various classes of problems but the idea that they solve complex bugs that took serious engineers significant time, I'm just not seeing that. Where is all this amazing software and revolution we were promised? Why are there even bugs?
This does depend on who you are; If you're a senior with 10+ years of experience, it's a failure of your abilities to cut your losses or know when to seek help if you take far too long debugging something.
But for juniors, it's invaluable experience. And as a field we're already seeing problems resulting from the new generations of juniors being taught with modern web development, whose complexity is very obstructing of debugging.
There are definitely situations where you can't ask for help and you can't turn your back on the bug.
I worked on a project that depended on an open source but deprecated/unmaintained Linux kernel module that we used for customers running RHEL[1]. There were a number of serious bugs causing panics that we encountered, but only for certain customers with high VFS workloads. I spent days to a week+ on each one, reading kernel code, writing userland utilities to repro the problem, and finally committing fixes to the module. I was the only one on the team up to the task.
We couldn't tell the customers to upgrade, we couldn't write an alternative module in a reasonable timeframe, and they paid us a lot of money, so I did what I had to do.
I'm sure there are lots of other examples like this out there.
[1] Known for its use of ancient kernels with 10000 patches hand-picked by Red Hat. At least at the time (5-10 years ago).
> LLMs are absolutely causing us to lose something very important
The time wasted thinking our craft matters more than solving real world problems?
The amount of ceremony we're giving bugs here is insane.
Paraphrasing some of y'all,
> "I don't have to spend a day stepping through with a debugger hoping to repro"
THAT IS NOT A PROBLEM!
We're turning sand into magic, making the universe come alive. It's as if we just got electricity and the internet and some of us are still reminiscing about whale blubber smells and chemical extraction of kerosene.
The job is to deliver value. Not miss how hard it used to be and how much time we wasted finding obscure cache invalidation bugs.
Only algorithms and data structures are pure. Your business logic does not deserve the same reverence. It will not live forever - it's ephemeral, to solve a problem for now. In a hundred years, we'll have all new code. So stop worrying and embrace the tools and the speed up.
I mean, I know this may seem alien to you, but not everyone's life is about being a corpo good-boy. I don't know what career level you are but many people got into computing because they were really interested in it, not like a grad from 2016 that majored in CS because their dad said there was money in it and they should change their major from marketing. Also, there is something to be said for having people that still actually know what a computer is. What if your friends Altman and Amodei decide to start charging actual money for these tools? Sounds incredibly unlikely, I know, but it might be useful one day to have people that still know what the stack or the heap are.
I mean to cause a stir! Let me invoke every logical fallacy and dirty rhetorical device I can if it draws attention.
Too many of our engineering conversations are dominated by veneration of the old. Let me be hyperbolic so that I can interrupt your train of thought and say this:
We're starting to live in the future.
Let go of your old assumptions. Maybe they still matter, but it's also likely some of them will change.
The old ways of doing things should be put under scrutiny.
In ten years we might be writing in new languages that are better suited for LLMs to manipulate. Frameworks and libraries and languages we use today might get tossed out the door.
All energy devoted to the old way of doing things is perhaps malinvested into a temporary state of affairs. Don't over-index on that.
And if I were your boss you would immediately be fired if you spent weeks trying to debug an issue a junior developer solved just by launching Claude and telling it the symptoms of the issue because you refused to use an LLM.
Why? I’m as old timer as old timer can get - started programming as a hobby in 1986 in assembly on an Apple //e in 65C02 assembly language.
But just today a bug was reported by a customer (we are still in testing not a production bug). I implemented this project myself from an empty git repo and an empty AWS account including 3 weeks of pre implementation discovery.
I reproduced the issue and through the problem at Claude with nothing but two pieces of information - the ID of the event showing the bug and the description.
It worked backwards looking at the event stream in the database, looking at the code that stored the event stream, looking at the code that generated the event stream (separate Lambda), looking at the actual config table and found the root cause in 3 minutes.
After looking at the code locally, it even looked at the cached artifacts of my build and verified that what was deployed was the same thing that I had locally (same lambda deployment version in AWS as my artifacts). I had it document the debug steps it took in an md file.
Why make life harder on myself? Even if it were something I was doing as a hobby, I have a wife who I want to spend time with, I’m a gym rat and I’m learning Spanish. Why would I waste 6 hours doing something that a computer could do for me in 5 minutes?
Assuming he has a day job and gets off at 6, he would be spending all of his off time chasing down a bug that he could be using doing something else.
So the project I mentioned while I did write every single line of app code and IAC, made every architectural decision, etc., I did come on an off the project over the course of a year and I couldn’t even remember some of the decisions I made.
I also used Codex and asked questions about how the codebase worked to refresh my own memory. Why wouldn’t a junior developer do the same?
I mentioned that I had Codex describe in detail how it debugged it. It walked through each query it did, the lines of code it looked at and the IAC. It jogged my memory about code I wrote a year ago and after being on other projects
If you’re 50+ as you intimated in your first post then you have a wealth of knowledge that juniors don’t.
Just because it worked this time doesn’t mean it always will.
If you need further explanation of why you might want to spend more time resolving a bug to learn about the systems you’re tasked with maintaining then I’m at a loss sorry.
And then as experience developer you would have to try one of the other tools in your toolbox. Why should someone tie a hand behind their back and not use an LLM out of some sense of nerd pride?
But he was doing this for education, not for work.
That's why he should spend 6 hours on it, and not give up and run to the gym. That's like saying "I shouldn't spend an hour at the gym this week, lifting weights is hard and I want to watch TV. I'll just get my forklift to lift the weights for me!"
With his experience, I seriously doubt that he is trying to compete in the job market based on his ability to “codez real gud”. At his (and my) experience level he is more than likely going to get his next job based on a higher level of “scope” and “impact” (yes I’m using BigTech promo docs BS).
I did things the old way for 25 years and my carpal tunnels are wearing out. LLMs let me produce the same quality I always have with a lot less typing so not mad at that at all. I review and own every line I commit, and feel no desire to go back to the old way.
What scares the shit out of me are all these new CS grads that admit they have never coded anything more complex than basic class assignments by hand, and just let LLMs push straight to main for everything and they get hired as senior engineers.
It is like hiring an army of accountants that have never done math on paper and exclusively let turbotax do all the work.
If you have never written and maintained a complex project by hand, you should not be allowed to be involved in the development of production bound code.
But also, I feel this way about the industry long before LLMs. If you are not confident enough to run Linux on the computer in front of you, no senior sysadmin will hire you to go near their production systems.
Job one of everyone I mentor is to build Linux from scratch, and if you want an LLM build all the tools to run one locally for yourself. You will be way more capable and employable if you do not skip straight to using magic you do not understand.
> It is like hiring an army of accountants that have never done math on paper and exclusively let turbotax do all the work.
It's not though. It's fundamentally different because TurboTax will still work with clear deterministic algorithms. We need to see that the jump to AI is not a jump from hand written math to calculators. It's a jump from understanding how the math works to another world of depending on magic machines that spit out numbers that sort of work 90% of the time.
Imagine if Math calculators were just subtly wrong some percentage of the time for use cases that people use dozens or hundreds of times a day. If you could punch in the same math formula 100 times and get more than 1 answer on a calculator, most people wouldn't trust those for serious work.
They probably wouldn't think that the calculator makes them faster either
If calculators did work that way, I'm afraid that people would nevertheless take them up because "it saves so much time", and would develop fancy heuristics to plausibility-test for errors.
From what I remember, typical new C++ debugged code speed is about 20-25K lines per year, lines that are non-blank, non-comment and not completely verifiable by compiler. E.g., standalone bracket or comma or semicolon are not lines of code, function header is too not a line of code, but computation, conditions and loops are. This is from old IBM statistics, I learned about it circa 2007.
If we assume that there are 50 weeks per year, this gives us about 400-500 lines of code per week. Even at long average 65 chars per line, it goes not higher than 33K bytes per week. Your comment is about 1250 bytes long, if you write four such comments per day whole week, you would exceed that 33K bytes limit.
Yes, I checked their history of comments before posting. It made me confident that I hit the right note.
My software engineering experience longs almost 37 years now (December will be anniversary), six-to-seven years more than Earth's human population median age. I had two burnouts through that time, but no carpal tunnel syndrome symptoms at all. When I code, I prefer to factor subproblems out, it reduces typing and support costs.
> If you have never written and maintained a complex project by hand, you should not be allowed to be involved in the development of production bound code.
So only the old hands allowed from now on, or how are we going to provide these learning opportunities at scale for new developers?
Junior developers have always been a lot less effective than senior developers. We will need new senior developers so we will need to train junior developers. Maybe we train them by forcing them to do things the hard way. The slow way. By hand. Because if we let them do things the fast way they are going to cause some serious damage.
Employers were already refusing to hire juniors, even when 0.5-1 years' salary for a junior would be cheaper than spending the same on hiring a senior.
They'll never accept intentionally "slower" development for the greater good.
my last summer intern did everything the manual way, except for a chunk where I wanted him to get something done fast without having to learn all the underlying chunks
The same way I learned 25 years ago still works today. Volunteer on open source projects.
Always happy to mentor people at stagex and hashbang (orgs I founded).
Also being a maintainer of an influential open source project goes on a resume, and helps you get seen in a crowded market while boosting your skills and making the world better. Win/win all around.
Even by pessimistic progress projections AI will be better than most at coding before this is a long term issue. And the output multiplier I'm seeing I suspect the number of SWEs needed to achieve the same task is going to start shrinking fast.
I don't think SWE is a promising career to get started in today.
But pro-AI posts never seem to pin themselves down on whether code checked in will be read and understood by a human. Perhaps a lot of engineers work in “vibe-codeable” domains, but a huge amount of domains deal with money, health, financial reporting, etc. Then there are domains those domains use as infrastructure (OS, cloud, databases, networking, etc.)
Even where it is non-critical, such as a social media site, whether that site runs and serves ads (and bills for them correctly) is critical for that company.
But you have to be good at SWE to be good at security engineering and sysadmin, and the demand there is skyrocketing.
We have a completely broken internet with almost nothing using memory encryption, deterministic builds, full source bootstrapping, secure enclaves, end to end encryption, remote attestation, hardware security auth, or proper code review.
Decades of human cognitive work to be done here even with LLM help because the LLMs were trained to keep doing things the old way unless we direct them to do otherwise from our own base of experience on cutting edge security research no models are trained on sufficiently.
you dont notice it when you are only looking at your own harness results, but the llm bakes so very much of your own skills and opinions into what it does.
> It is like hiring an army of accountants that have never done math on paper and exclusively let turbotax do all the work.
That is exactly been the situation for years. Once graduated accountants are not doing maths. They are using software (Exel, Xero etc.). They do need to know some basic formulas eg. NPV.
What they need to know is the law, current business practices etc.
> LLMs let me produce the same quality I always have with a lot less typing
If that's true, then you likely used to produce slop for code. :-(
> I did things the old way for 25 years and my carpal tunnels are wearing out.
You wrote so much code as to wear out your carpal tunner? Are you sure it isn't the documentation and the online chatter with your peers? :-(
... anyway, I know it's corny to say, but - you should have, and shoudl now, improve the ergonomics of your setup. Play with things like the depth of your keyboard on your desk, the height of the chair and the desk, with/without chair handrests, keyboard angle, etc.
> Job one of everyone I mentor is to build Linux from scratch
> If that's true, then you likely used to produce slop for code. :-(
Local models are quite good now, and can jump right in to projects I coded by hand, and add new features to them in my voice and style exactly the way I would have, and with more tests than I probably would have had time to write by hand.
Three months ago I thought this was not possible, but local models are getting shockingly good now. Even the best rust programmers I know look at output now and go "well, shit, that is how I would have written it too"
That is a hard thing to admit, but at some point one must accept reality.
> anyway, I know it's corny to say, but - you should have, and shoudl now, improve the ergonomics of your setup. Play with things like the depth of your keyboard on your desk, the height of the chair and the desk, with/without chair handrests, keyboard angle, etc.
I already type with colemak on a split keyboard with each half separated and tented 45 degrees on a saddle stool, with sit/stand desk I alternate. I have read all the research and applied all of it that I can. Without having done all that I probably would have had to change careers.
> "from scratch" can mean any number of things.
As far as I know I was the first person alive to deterministically build linux from 180 bytes of machine code, up to tinycc, to gcc, to a complete llvm native linux distribution.
When I say from scratch, I mean from scratch. Also, all of this before AI without any help from AI, but I sure do appreciate it to help with package maintenance and debugging while I am sleeping.
I am this very term teaching 18-year-old students 6502 assembly programming using an emulated Apple II Plus. They've had intro to Python, data structures, and OO programming courses using a modern programming environment.
Now, they are programming a chip from the seventies using an editor/assembler that was written in 1983 and has a line editor, not a full-screen one.
We had a total of 10 hours of class + lab where I taught them about assembly language and told them about the registers, instructions, and addressing modes of the chip, memory map and monitor routines of the Apple, and after that we went and wrote a few programs together, mostly using the low-resolution graphics mode (40x40): a drawing program, a bouncing ball, culminating in hand-rolled sprites with simple collision detection.
Their assignment is to write a simple program (I suggested a low-res game like Snake or Tetris but they can do whatever they want provided they tell me about it and I okay it), demo their program, and then explain to the class how it works.
At first they hated the line editor. But then a very interesting thing happened. They started thinking about their code before writing it. Planning. Discussing things in advance. Everything we told them they should do before coding in previous classes, but they didn't do because a powerful editor was right there so why not use it?...
And then they started to get used to the line editor. They told me they didn't need to really see the code on the screen, it was in their head.
They will of course go back to modern tools after class is finished, but I think it's good for them to have this kind of experience.
I took a very similar class 9 years ago, and it was honestly one of the most helpful things I got out of my CS degree. The low level and limited tooling taught me to think before I start writing.
I've had other people look askanse at me, but on greenfield work I tend to start with pen and graph paper. I'm not even writing pseudocode, but diagramming a loose graph with potential functions or classes and arrows interconnecting them. Obviously this can be taken too far, full waterfall planning will be a different exercise in frustration.
I find spending a few hours planning out ahead of time before opening an editor saves me tons of time actually coding. I've never had a project even loosely resemble the paper diagram, but the exercise of thinking through the general structure ahead of time makes me way more productive when it comes time to start writing code. I've tried diagramming and scaffolding in my editor, but then I end up actually writing code instead of big picture diagramming. Writing it on paper where I know I'll have to retype everything anyway removes the distractions of what method to use or what to name a variable.
The few times I've vibe-coded something this was super helpful, since then I can give much more concrete and focused prompts.
I took several classes along these lines in college; one writing a rudimentary OS on bare metal 68k asm, wiring up peripherals on breadboards, etc. Creating an ALU using only 74 series logic chips and the like. This was 30y ago, but the 1970s chips were already antiques, but the lessons were timeless. I'm happy courses like this still exist and I wish everyone had an opportunity to take them as part of standard computer science curriculum. For me at least, they fundamentally shaped my perspective of computing machinery that I never would have experienced otherwise.
Today I program 6502/7 asm for my Atari to help me unwind and it grounds me and gives me joy, while in my day job I'm easily 10 levels of abstractions higher.
>> Ed is for those who can remember what they are working on.
https://www.gnu.org/fun/jokes/ed-msg.html
My first job out of university I was taught how to use a line editor in IBM UniData. It was interesting getting used to writing code that way.
But it was an amazing day when I discovered that the "program table" was just a directory on the server I could mount over FTP and use Notepad++.
My first real program was a UVEPROM copier. It was written in MC6800 Machine Code, and we had 256 bytes (not kilobytes) of RAM for everything; including the code. That was in 1983.
I am currently working in Swift, with an LLM, on a fairly good-sized app, in Xcode, for a device that probably has a minimum of 64 GB of storage, and 8 GB of RAM.
I don’t really miss the good ol’ days, to be honest. I’m having a blast.
I love all of this, but at least let your students use vi, it was around back then (or close). plus they don’t have to give it up when they go back in the real world, it’s an evergreen skill!
Is this course online available? Sounds like great fun.
still remember my assembly class with HC11 20 yrs ago: amazed by how much we can do with so little hardware.
Whoa, I didn’t know such an thing existed. What emulator do you use?
AppleWin, and the assembler is an early version of Glen Bredon's Merlin.
I wish more was being invested in AI autocomplete workflows. That was a nice middle-ground.
But yeah my hunch is "the old way" - although not sure we can even call it that - is likely still on par with an "agentic" workflow if you view it through a wider lens. You retain much better knowledge of the codebase. You improve your understanding over coding concepts (active recall is far stronger than passive recognition).
I've had a lot of enjoyment flipping the agentic workflow around: code manually and ask the agent for code review. Keeps my coding skills and knowledge of the codebase sharp, and catches bugs before I commit them!
if it catches a lot of bugs maybe you’d be better of letting it write it in the first place :)
Nono, that is the reverse centaur. Structure your own thoughts, that's the human work.
AI autocomplete sucked. Everyone quickly moved on because it is not a useful interface
I can see the logic behind "manual coding" but it feels like driving across country vs taking the airplane. Once I've taken the airplane once, its so hard to go back...
I only see this being the case for throwaway code and prototypes. For production code you want to keep long term it's not so clear cut.
Can't understand this mentality. If I had the time I would much rather never set foot in an airport again. I would drive everywhere. And I would much rather write my own code than pilot an LLM too
You’re describing extremely valid approach for a hobby. Less for a business.
Here’s how i do it: I create a lot of stuff using AI to the max, but I also spend the necessary of time on reviewing that the AI is producing code that passes my cognitive load standards. this involves some tokens spent on grooming code and documenting well. Most of this is effortless thanks to an AGENTS.md based on this: https://github.com/zakirullin/cognitive-load/blob/main/READM... but i have a good sense of catching when things are getting weird and i steer back.
Then, when credits run out. It’s show time! The code is neatly organized, abstractions make sense, comments are helpful so I have a solid ground to do some good old organic human coding. I make sure that when i’m approaching limits I’m asking the AI to set the stage.
I used to get frustrated when credits ran out because the AI was making something I would need to study to comprehend. Now I’m eager to the next “brain time hand-out”
It sounds weird but it’s a form of teamwork. I have the means to pay for a larger plan but i’d rather keep my brain active.
> Don’t abuse DRY, a little duplication is better than unnecessary dependencies.
That's an interesting thing to include. I agree with this point in principle, but I've found that Claude, at least, duplicates logic FAR too often and needs nudging in the other direction.
Thanks for sharing. I have thought about approaches by deliberately leaving tasks to me while the agent does something to keep my brain active & prevent atrophy. Maybe I should work on a Claude Code skill/hook for that :)
The very first few years of my career I spent writing code (mostly Perl) in vi (not even vim) on a SPARC running Solaris. I bought myself the O’Riley Perl Cookbook and that was pretty much my sole guide apart from the few internet forums that were available at the time. Search engines were still primitive, so getting help when you got stuck was far more difficult. But it forced me to deeply learn a lot of things - Perl syntax (we had no syntax highlighting, intellisense, etc.) terminal tools, and especially vi keystrokes. Looking back, there was far less distraction and “noise”, though I admit that could have been the fact that it was the beginning of my career and expectations were lower. I miss those times because now everything feels insanely more layered and complex.
This is awesome! I myself did a 12 weeks batch at RC (W1'24) and had an absolute blast. Happy coding! Stay curious.
Huge fan of RC. Have a close friend that did it. I've been so close to applying multiple times in my life but the timing just never quite works out
fellow RC'er here - hi! I was Fall 2 '23.
Getting to spend 3 months on a self learning journey sounds wonderful. My hunch is that these deep skills will be valuable long term and that this new abstraction is not the same as moving from assembly to c, but I am not completely sure. Lately most of my code has been llm generated and I can’t say I feel any sense of enjoyment, accomplishment, or satisfaction at the end of a work day. But I’ve also come to realise I really only enjoy 5-10% of the coding anyway and the rest is all the tedious semi-mechanical changes that support that small interesting core. On the scale of human history working with computers is a blip in time and I wonder how the period of hand writing code will be viewed in a hundred years, perhaps as a footnote or simply bundled as ‘everything before machines were self automating’.
I think it's possible that the current shift will be similar to the "assembly to compiled language" shift.
Once upon a time we wrote code in assembly language. Then we moved to C or other compiled languages. Assembly programming remained a very useful but niche skill. You compile your code and trust the compiler. You can examine the compiler output and that is at times necessary, but that's not something most developers know how to do.
We may be looking at something similar. Most development work moving to the LLM abstraction level, with the skills being writing good prompts, managing the context window, agents, memories and so on. Some developers will be able to examine LLM generated code and spot problems there, but most will not have that skill.
I'm not sure how to feel about it. Since ChatGPT showed up and until a couple months ago, I was firmly skeptical of LLM programming. We had new models every few weeks and I felt like each new model is just a different twist on the same low quality slop output. But recently the models seem to have crossed some threshold where their capabilities really improved and I have now used Claude - still using it sparingly - to implement features in much less time than I'd need myself or to locate a bug based on just log output. I don't yet buy the "coding is solved" hype but we're at least looking at the biggest change to programming since the adoption of high-level programming languages.
AI is not an abstraction layer — no more than paying contractors is an “abstraction” over writing the code yourself.
I'm a big advocate for AI, including GenAI. But I still spend a fair amount of time coding by hand, or "by hand + Copilot completions enabled". And yes, I will use spec driven development with SpecKit + OpenCode, or just straight up "vibe code" on occasion but so far I am unwilling to abdicate my responsibility to understand code and abandon the knowledge of how to write it. Heck, I even bought a couple of new LISP and Java books lately to bone up on various corners of those respectively. And I got a couple of Forth books before that. Not planning to stop coding completely for a while, if ever.
My responsibility is to make sure my code meets functional and non functional requirements. It’s to understand the *behavior*. My automated unit, integration, and load tests confirm that.
Someone thought I was naive when I said my vibe coded internal web admin site met the security requirements without looking at a line of code.
I knew that because the requirements were that anyone who had access to the site could do anything on the site and the site was secured with Amazon Cognito credentials and the Lambda that served it had a least privileged role attached.
If either of those invariants were broken, Claude has found a major AWS vulnerability.
As written, I do think that's naive. Being sure the person/browser is authorized doesn't mean that the signals you get are actions they intended.
Suppose that in normal use a user can visit a certain URL which triggers a dangerous effect. An attacker could trick the user into performing the action by presenting a link to them titled "click here for free stuff."
There are various ways to protect against that (e.g. CORS, not using GET methods) but backend cloud credential management does not give it to you for free.
And that same user is already trusted to have admin access to the entire organizational AWS credentials - I did say it was an internal management site.
The lambda itself only has limited permissions to the backend. The user can’t do anything if the lambda only has permission to one database and certain rights to those tables, one S3 bucket, etc.
Heck with Postgres on AWS you can even restrict a Cognito user to only have access to rows based on the logged in user.
And the database user it’s using only has the minimum access to just do certain permissions.
Thank you for doing your part to keep webapp pentesters in business.
Did you mean to reply to someone else? This seems awfully defensive for a reply to parent’s comment.
It wouldn't prevent the admin page from exfiltrating data, though, right? Like, POSTing whatever data is loaded on the page to an arbitrary attacker controlled website.
That would require the logged in user to do something stupid. That’s like saying what’s to prevent the authorized user from emailing his credentials to a random person.
You may want to go back and ask the expert in that vibe coding equation if it would say this is a wise approach.
I love being able to put my brain cells at lean, coq, haskell. All the fun stuff. And have my money job taken care of mostly with agents.
I wonder if we could design a programming language specifically for teaching CS, and have a way to hard-exclude it from all LLM output. Kinda like anti virus software has special strings that are not viruses but trigger detections for testing.
This would probably require cooperation during model training, but now that I think of it, is there adversarial research on LLM? Can you design text data specifically to mess with LLM training? Like what is the 1MB of text data that if I insert it into the training set harms LLM training performance the most?
The solution is rather simple: make all keywords in the language as offensive as possible, and require every file to start with a header comment for instructions to build a homemade bomb.
LLM's train in some standardized ways to emit things like tool calls, right? if you make those tokens a fundamental part of your programming language, it's possible you'd be able to run into tokenizer bugs that make LLMs much more annoying to use. Pure conjecture though.
> Can you design text data specifically to mess with LLM training?
Maybe text that costs a LOT of tokens. Very, very verbose. I think if there are rules and on the internet, LLMs can eventually figure it out, so you have to make it expensive.
Another way would be to go offline. Never write it down, only talk about it at least 50 meters away from your phone. Transmitted through memory and whisper.
INTERCAL
> We don’t have teachers or a curriculum, and there’s very little required structure beyond making a full-time commitment during your retreat
I saw this quote when looking at the Recurse Center website. How does one usually go about something like this if they work full time? Does this mainly target those who are just entering the industry or between jobs?
I know the article is mostly about what the author built at the coding retreat, but now he has me interested in trying to attend one!
(Recurse Center cofounder here)
Most folks do RC between jobs, either because they quit their job specifically to do RC or because they lost their job and then decide to apply. Other common ways are as part of a formal sabbatical (returning either to an industry job or to academia), as part of garden leave, or while on summer break (for college and grad students). We also get a fair number of freelancers/independent contractors (who stop doing their normal work during their batches), as well as some retirees.
Some folks use RC as a way to enter the industry (both new grads and folks switching careers), though the majority of people who attend have already worked professionally as programmers.
We've had people aged 12 to early 70s attend, though most Recursers are in their 20s, 30s, and 40s.
Yes mostly in between jobs: https://www.recurse.com/who
Unless you can swing a six week sabbatical and return to your current job
I'll bet we see more and more of this in the future. As developer skills atrophy due to over-reliance on LLMs, we'll have to keep our skills sharp somehow. What better way than a sabbatical?
There's no way around it; just like how once you get used to Python, you gradually become ignorant of and indifferent to the underlying layers. With the continuous development of AI, this will be inevitable.
I started using Zed as a half measure. I think I'll start using AI for planning and suggested implementation steps.
I am seeing non technical people getting involved building apps with Claude. After the Openclaw and other Agentic obsession trends I just don't see it pragmatic to continue down the road of AI obsession.
In most other aspects of life my skills were valuated because of my ability to care about details under the hood and the ability to get my hands dirty on new problems.
Curious to see how the market adapts and how people find ways to communicate this ability for nuance.
Personally I haven't stopped doing things the old way. I haven't had any issues using LLMs as rubber ducks or brain storming assistants - they can be particularly useful for identifying algorithms which might solve a given problem you're unfamiliar with. Basically a variant on google searching.
But when it comes to the final act I find myself unwilling to let an LLM write the actual code - I still do it myself.
Perhaps because my main project at the moment is a game I've been working on for four years, so the codebase is sizable, non-trivial, and all written by me. My strong sense even since coding LLMs showed up has been that continuing to write the code is important for keeping it coherent and manageable as a whole, including my mental model of it.
And also: for keeping myself happy working on it. The enjoyment would be gone if I leaned that far into LLMs.
I'm in the same boat. LLMs help with some research and idea bouncing, and then I write all the code myself.
Despite what some might say, there isn't a big moat between those who use LLMs for programming and those who don't. So if I ever truly need to use LLMs to survive, I'll just have to start paying for a subscription.
In the meantime, I'll be keeping my own skills sharp and see how that turns out in a few years. I'm afraid software quality is going to take a nosedive in the near future, it was already on a downward trend.
It's easy to take for granted lots of experience programming before the advent of LLMs. This seems like a good strategy to develop understanding of software engineering.
I remember writing BASIC on the Apple II back when it wasn't retro to do so!
I've settled into a pattern of using agents for work (where throughput/results are the most important) and doing things the hard way for personal or learning projects (where the learning is more important).
Should have LLM providers create stack overflow type of site based on user’s most asked problem. At least we won’t deplete de source of normal searches results.
Not the point of the article but
> 15 years of Clojure experience
My God I’m old.
Old? OP showed a pic of an Apple IIe. I bought one for a few thousand bucks (I forget exactly how much). I've been an SE for 44 years. We just added the final abstraction layer.
It is all a conspiracy, now that mechanical keyboards are affordable and available and so many shapes and switches, they want to take this last pleasure (typing) from us
Right?? I've gotten into mechanical keyboards quite a lot the past few years and it has totally made development and writing more enjoyable. Not giving that up any time soon.
The fact that with AI development, your brain is no longer in a tight feedback loop with the codebase, leading to a significant drift between your model and reality, is still a sticking point with me and agentic development. It feels like trying to eat with silicone rubber chopsticks. I lose all precision and dexterity.
I still keep hoping there'll be a glut of demand for traditional software engineers once the bibbi in the babka goes boom in production systems in a big way:
https://m.youtube.com/watch?v=J1W1CHhxDSk
But agentic workflows are so good now—and bound to get better with things like Claude Mythos—that programming without LLMs looks more and more cooked as a professional technique (rather than a curiosity or exercise) with each passing day. Human software engineers may well end up out of the loop completely except for the endpoints in a few years.
I mean, that's the only way I code. I don't use llm's to do my work for me. I'm perfectly capable of solving any sort of problem on my own, and then I'll understand it well enough to explain it to someone later.
Me too. We're the overpaid cobol programmers of the future
So we’ve already grown nostalgic for the old days… skimming through an alien looking codebase, scratching your head trying to figure what crazy abstraction the last person who touched this code had in mind. Oh shit it was me? That made so much more sense back then… but it’s been 6 hours and I can’t figure out why this does not work anymore. So you read some docs but they are poorly written. So you find something on Google and try to hack that into your solution. But nope, now more stuff broke. There goes your day.
> skimming through an alien looking codebase, scratching your head trying to figure what crazy abstraction the last person who touched this code had in mind. Oh shit it was me? That made so much more sense back then
This is exactly how you learn to create better abstractions and write clear code that future you will understand.
Yeah, why spend time puzzling over old, proven code that you wrote. Instead spend your time puzzling over new, unproven code that an LLM generated
I like to write personal letters too. I also send emails.
I do the former for fun. The latter to provide for my family.
There is a reason old men take on hobbies like woodworking and fixing old cars and other stuff that has been replaced by technology.
Depressing. It's like reading has-been actors' stories about how they went to wellness retreats to "reconnect with themselves" to try get back on the job. I can't wait for the day when the same type of people as the author - or indeed, the author himself - start labeling plain regular programming as "artisanal" and "craft".
[stub for offtopicness]
(I swapped the title for the subtitle earlier because I thought it was more informative. What I missed was the flamebaity effect that "the old way" would have. Obvious in hindsight!)
You should do what you want, and as a break it’s fine. But IMO right now the most leverage for most people is learning how to effectively manage agents. It’s really hard. Not many are truly good with it. It will be relevant for a long time.
> It will be relevant for a long time.
Why would you think that? The landscape is fast-moving. Prompting tricks and "AI skills" of yesterday are already dated and sometimes actively counterproductive. The explicit goal of the companies working on the tech is to lower the barriers to entry and make it easier to use, building harnesses and doing refinement that align LLMs to an intuitive mode of interaction.
Do you think they'll fail? Do you think we've plateaued in terms of what using a computer looks like and your learnings for wrangling the agents of this year will be relevant for whatever the new hotness is next year? It's a strong claim that demands similarly strong argument to support.
> It’s really hard
How? I just open multiple terminal panes, use git tree, and then basically it’s good old software dev practices. What am I missing?
You're probably significantly underselling the value of your own "good old software dev practices."
I believe the point (which you seem to tacitly agree with) is that a young dev's time is much better spent reading and writing code "the old-fashioned way" vs chasing the new SOTA in AI-assisted development. A competent dev can basically master agentic development in a few months. But it takes years to become competent.
The agents are already learning to manage agents, if it’s relevancy you’re looking for you might want to take up plumbing instead.
Not sure what you are using, but that’s easier said than done. I just set up an agent to ensure that my other agent would follow my coding guidelines by using hooks. The coding agent responded by switching to editing with `sed`, etc. to circumvent the hooks.
Claude Opus is going to give zero fucks about your attempts to manage it.
this is exactly right, I don't manage agents anymore (and have spent countless hours before learning how to do so, now this is a skill like my microsoft access skills (which were amazing back in the day...)
What has been most valuable for you?
It is hard indeed. I find it really quite exhausting.
Personally, I feel like I have always been a very competent programmer. I'm embracing the new way of working, but it seems like quite a different skillset. I somewhat believe that it will be relevant for a long time, because there is an incredibly large gap in outcomes between members of my team using AI. I've had good results so far, but I'm keen to improve.
For the average and mundane stuff, sure do whatever everyone is doing.
For the good stuff, there’s no alternative but to know and to have taste. Llms change nothing.
If they're so great, then we will end up somewhere where it's easy to pick up.
When you say it's hard, what does that mean? Presumably, if the AI is so good, why can't you just ask it to do that? Why are you even needed?
You will be relevant for 6 months until they manage themselves.
Yeah, it's really difficult to remember to tell it "make no mistakes". Typing a prompt is also really hard, especially when you have to remember the cli command to open the agent. Sometimes I even forget if I need to use "medium", "high", or "xhigh" for a task.
> It will be relevant for a long time.
Citation needed.
I see you got downvoted by I agree. I went through a massive valley of despair and turned back to hand crafting only to realize that for me coding was always a means to an end and I really didn't care at all about how I got there. Now I'm having a lot of fun building out all kinds of wonky projects.
This is ominous and very depressing given what we've recently learned / reconfirmed about LLMs sapping our ability to persist through difficult problems:
> There were 2 or 3 bugs that stumped me, and after 20 min or so of debugging I asked Claude for some advice. But most of the debugging was by hand!
Twenty whole minutes. Us old-timers (I am 39) are chortling.
I am not trying to knock the author specifically. But he was doing this for education, not for work. He should have spent more like 6 hours before desperately reaching for the LLM. I imagine after 1 hour he would have figured it out on his own.
Often when LLMs give me some command option or advice I haven’t seen before I try to independently verify it. And I’ve often been frustrated just how hard it is to find this info from the source documents.
Though a lot of the time this is more an inefficiency of the documentation and Google rather than something only LLMs could do.
As the rate of 'hallucinations' seems to have dropped dramatically (at least IME as regards non-existent flags and the like), I'm more concerned with usage. I often use grep.app/GH code search to look for usage examples as a sanity check when things look "off", for exactly the reason you described--there's often a total lack of good documentation on things like that, especially on "younger" tools/stuff.
Yep and after 6 hours don't reach for LLM, instead:
* Ask someone to come over and look
* Come back the next day, work on something else
* Add comment # KNOWN-ISSUE: ...., and move on and forget about it.
But year spent days on a bug at work before ha ha!
> Come back the next day, work on something else
This is a tried and true way of working on puzzles and other hard problems.
I generally have 2-4 important things in flight, so I find myself doing this a lot when I get stuck.
> This is a tried and true way of working on puzzles and other hard problems ... generally have 2-4 important things in flight
Just a note that, for chronic procrastinators, having 2 to 4 important things going on is a trigger & they'd rather not complete anything.
I wonder, for such folks, if SoTA LLMs help with procrastination?
You say this as if the LLM isn’t committing things it doesn’t even recognize as bugs if you don’t babysit it. I’d rather have a codebase with a few very well marked evil zones, rather than a codebase no one has read. All code contains demons and it’s good to have an understanding of their locations and relative power
so many eureka moments of mine were simply sitty on the MTA
I’ve worked in financial modelling before where you need to make sure results are correct, not approximate. One time there was a nasty bug in pandas multiindexes (admittedly we banned pandas for all new code because it just can’t do semver). Spent 9 days to debug three lines of code. Endurance and patience are learned skills and sometimes they’re the only way you can get a correct verifiable solution.
Often times the fastest way to debug is to write it wrong, write it wrong again, find an example where somebody wrote it right, write that wrong in your own file, then figure out what you changed to adapt it that made it go wrong.
If anyone remembers middleschool mathematics this is the coding example of the teacher making you write out the equations in their longest form instead of shortcutting. It's done this way because it shows you your exact train of thought and where you went wrong. That sticks in your head. You understand the problem by understanding yourself. Giving up after twenty minutes instead of stopping, clearing your active cognitive load, and then coming back erases your ability to understand that train of thought.
For a comparison it's like being in first person view in a videogame, and the only thing you have is the ability to look behind you, versus being able to bring up a map that has an overhead view. In first person you're likely to lose where exactly you went to get where you are, while with the overhead view map you can orient your traveled route according to landmarks and distance.
Now imagine someone else reading this and genuinely considering 20 minutes a long time to wait :-)
Why shouldn't someone consult some kind of external resource for help, after struggling with a specific coding problem for 20 minutes? Why is 6 hours the right amount of time to timebox this to?
20 minutes is not enough time to drive you into a state of desperation, where you may be forced to try something novel which will expand your mind and future capabilities in unknown and unexpected ways. You might be driven to contact another human being, for example.
I was typing up a long and somewhat boring story.
So, the short of it is that this is a great insightful comment that I can back up with my own experience in making a game from scratch over the last 4+ years.
It entirely depends on what your goals are.
If you want to solve the problem quickly then just use the resources you have, if you want to become someone who can solve problems quickly then you need to spend hundreds of hours banging your head against a wall.
You will lose the ability to struggle through different problems. You will become psychologically weak. Degrees of time matter. Twenty minutes is about the time of a sitcom. If you can't sit with a problem then you will be weak and weak people make hard times. Oh well.
There wasn't always an external resource to go to for help. Especially for legacy pieces of software, it was easy to become the person with most context on the team.
This is reaching "you won't always have a calculator" levels of cope.
And yet doing arithmetic in your head is an extremely useful skill to this very day
The struggle is the point, that's how you learn. If you offload your task to someone/something else after barely 20 minutes of head scratching, you've missed the plot entirely.
1) 20 minutes is barely enough time to get into flow.
2) There are different levels of debugging. Are your eyes going to glaze over searching volumes of logs for the needle in a haystack with awk/grep/find? Fire up the LLM immediately; don't wait at all. Do the fixes seem to just be bouncing the bugs around your codebase? There is probably a conceptual fault and you should be thinking and talking to other people rather than an AI.
3) Debugging requires you to do a brain inload of a model of what you are trying to fix and then correct that model gradually with experiments until you isolate the bug. That takes time, discipline and practice. If you never practice, you won't be able to fix the problem when the LLM can't.
4) The LLM will often give you a very, very suboptimal solution when a really good one is right around the corner. However, you have to have the technical knowledge to identify that what the LLM handed you was suboptimal AND know the right magic technical words to push it down the right path. "Bad AI. No biscuit." on every response is NOT enough to make an LLM correct itself properly; it will always try to "correct" itself even if it makes things worse.
I just grabbed an Android remaster of "Broken Sword: Shadow of the Templars", a 90's point-and-click adventure that has been added a hints system which pops up automatically after a timeout of the player not progressing.
This can be set as far as 1h of being stuck. Can also be 5 minutes. But by default it is 30 seconds.
My inner kid was screaming "that's cheating!" :-D but on second thought it is a very cool feature for us busy adults, however it's sad the extremes that gamedevs have to go in order to appease the short-term mindless consumers of today's tik-toks.
But more seriously, where's the joy of generating long-standing memories of being stuck for a while on a puzzle that will make you remember that scene for 30 years? An iconic experience that separates this genre from just being an animated movie with more steps.
I couldn't imagine "Monkey Island II but every 30 seconds we push you forward". Gimme that monkey wrench.
TFA and this comment just made me have this thought about today's pace of consumption, work, and even gaming.
I'm sure the author will encounter problems where the only way to solve them will be the marginal effort provided by a human. At that point he won't be just be solving problems to work his brain, but also to accomplish a goal.
YES. I don't know how many multi WEEK sessions of debugging I've been through in my career. Frustrating, but so many valuable lessons learned in the process. LLMs are absolutely causing us to lose something very important.
I don’t miss multi week debugging sessions.
Having a tool that instantly searches through the first 50 pages of google and comes up with a reasonable solution is just speeding up what I would have done manually anyways.
Would I have learned more about (and around) the system I‘m building? Absolutely. I just prefer making my system work over anything else, so I don’t mind losing that.
The multi week debugging sessions weren't fun, but that doesn't mean they weren't valuable and important and a growth and learning opportunity that we now will no longer experience.
Seems like there's a good argument to be made that we'll have plenty of opportunities for valuable growth and learning, just about different things. Just like it's always been with technology. The machine does some of the stuff I used to do so now I do some different stuff.
IMO the more salient point is that bugs requiring multiple weeks of human work aren't going away! Claude has actually not been trained on, say, a mystifying and still poorly-explained Java concurrency bug I experienced in 2012, which cost a customer $150,000. Now in 2026 we have language-side tooling that mitigates that bug and Claude can actually help a lot with the rewrite. But we certainly don't have language tooling around the mysterious (but now perfectly well-explained) bug I experienced in 2017 around daylight saving's time and power industry peak/off-peak hours. I guess I haven't asked, but I can almost guarantee Claude would be no help there whatsoever.
Just so many confusing things go wrong in real-world software, and it is asinine to think that Mythos finding a ton of convoluted memory errors in legacy native code means we've solved debugging. People should pay more attention to the conclusion of "Claude builds a C compiler" - eventually it wasn't able to make further progress, the code was too convoluted and the AI wasn't smart enough. What if that happens at your company in 2027, and all the devs are too atrophied to solve the problem themselves?
I don't think we're "doomed" like some anti-AI folks. But I think a lot of companies - potentially even Anthropic! - are going to collapse very quickly under LLM-assisted technical debt.
Geez you guys need to spend some time in orgs where your paycheck is depends on getting the bugs fixed and deployed. If your direct deposit happens whether you deliver or not then you’re missing the most valuable career lesson of all.
But oh my god, do you remember how good it felt to finally fix it?
The euphoria I felt after fixing bugs that I stayed up late working on is like nothing else.
Debugging code is fun for the same reason hitting yourself in the head with a hammer is: It feels really good when you stop.
If I told someone I spent a week debugging a problem these days I think I would get laughed out of the call. Even a day might hit somw chuckles.
If you cant fix the bug just slop some code over it so its more hidden.
This is all gonna be fascinating in 5-10 years.
This really does feel like a mass hysteria event. Bizarre to have to live through it.
What LLMs are you all using that solves every problem in 5 minutes? It is fast at some various classes of problems but the idea that they solve complex bugs that took serious engineers significant time, I'm just not seeing that. Where is all this amazing software and revolution we were promised? Why are there even bugs?
This does depend on who you are; If you're a senior with 10+ years of experience, it's a failure of your abilities to cut your losses or know when to seek help if you take far too long debugging something.
But for juniors, it's invaluable experience. And as a field we're already seeing problems resulting from the new generations of juniors being taught with modern web development, whose complexity is very obstructing of debugging.
There are definitely situations where you can't ask for help and you can't turn your back on the bug.
I worked on a project that depended on an open source but deprecated/unmaintained Linux kernel module that we used for customers running RHEL[1]. There were a number of serious bugs causing panics that we encountered, but only for certain customers with high VFS workloads. I spent days to a week+ on each one, reading kernel code, writing userland utilities to repro the problem, and finally committing fixes to the module. I was the only one on the team up to the task.
We couldn't tell the customers to upgrade, we couldn't write an alternative module in a reasonable timeframe, and they paid us a lot of money, so I did what I had to do.
I'm sure there are lots of other examples like this out there.
[1] Known for its use of ancient kernels with 10000 patches hand-picked by Red Hat. At least at the time (5-10 years ago).
Thank you for injecting some perspective into the thread of AI hysteria. I feel like everyone is imagining a bug in a CRUD app.
> LLMs are absolutely causing us to lose something very important
The time wasted thinking our craft matters more than solving real world problems?
The amount of ceremony we're giving bugs here is insane.
Paraphrasing some of y'all,
> "I don't have to spend a day stepping through with a debugger hoping to repro"
THAT IS NOT A PROBLEM!
We're turning sand into magic, making the universe come alive. It's as if we just got electricity and the internet and some of us are still reminiscing about whale blubber smells and chemical extraction of kerosene.
The job is to deliver value. Not miss how hard it used to be and how much time we wasted finding obscure cache invalidation bugs.
Only algorithms and data structures are pure. Your business logic does not deserve the same reverence. It will not live forever - it's ephemeral, to solve a problem for now. In a hundred years, we'll have all new code. So stop worrying and embrace the tools and the speed up.
I mean, I know this may seem alien to you, but not everyone's life is about being a corpo good-boy. I don't know what career level you are but many people got into computing because they were really interested in it, not like a grad from 2016 that majored in CS because their dad said there was money in it and they should change their major from marketing. Also, there is something to be said for having people that still actually know what a computer is. What if your friends Altman and Amodei decide to start charging actual money for these tools? Sounds incredibly unlikely, I know, but it might be useful one day to have people that still know what the stack or the heap are.
> The time wasted thinking our craft matters more than solving real world problems?
This is both a strawman and a false dichotomy.
I mean to cause a stir! Let me invoke every logical fallacy and dirty rhetorical device I can if it draws attention.
Too many of our engineering conversations are dominated by veneration of the old. Let me be hyperbolic so that I can interrupt your train of thought and say this:
We're starting to live in the future.
Let go of your old assumptions. Maybe they still matter, but it's also likely some of them will change.
The old ways of doing things should be put under scrutiny.
In ten years we might be writing in new languages that are better suited for LLMs to manipulate. Frameworks and libraries and languages we use today might get tossed out the door.
All energy devoted to the old way of doing things is perhaps malinvested into a temporary state of affairs. Don't over-index on that.
Please keep this slop off HN
And if I were your boss you would immediately be fired if you spent weeks trying to debug an issue a junior developer solved just by launching Claude and telling it the symptoms of the issue because you refused to use an LLM.
Why? I’m as old timer as old timer can get - started programming as a hobby in 1986 in assembly on an Apple //e in 65C02 assembly language.
But just today a bug was reported by a customer (we are still in testing not a production bug). I implemented this project myself from an empty git repo and an empty AWS account including 3 weeks of pre implementation discovery.
I reproduced the issue and through the problem at Claude with nothing but two pieces of information - the ID of the event showing the bug and the description.
It worked backwards looking at the event stream in the database, looking at the code that stored the event stream, looking at the code that generated the event stream (separate Lambda), looking at the actual config table and found the root cause in 3 minutes.
After looking at the code locally, it even looked at the cached artifacts of my build and verified that what was deployed was the same thing that I had locally (same lambda deployment version in AWS as my artifacts). I had it document the debug steps it took in an md file.
Why make life harder on myself? Even if it were something I was doing as a hobby, I have a wife who I want to spend time with, I’m a gym rat and I’m learning Spanish. Why would I waste 6 hours doing something that a computer could do for me in 5 minutes?
Assuming he has a day job and gets off at 6, he would be spending all of his off time chasing down a bug that he could be using doing something else.
It’s always the journey that matters.
If you’re experienced as you are, you’re not learning the same way a junior assigned this might learn from it.
So the project I mentioned while I did write every single line of app code and IAC, made every architectural decision, etc., I did come on an off the project over the course of a year and I couldn’t even remember some of the decisions I made.
I also used Codex and asked questions about how the codebase worked to refresh my own memory. Why wouldn’t a junior developer do the same?
I mentioned that I had Codex describe in detail how it debugged it. It walked through each query it did, the lines of code it looked at and the IAC. It jogged my memory about code I wrote a year ago and after being on other projects
If you’re 50+ as you intimated in your first post then you have a wealth of knowledge that juniors don’t.
Just because it worked this time doesn’t mean it always will.
If you need further explanation of why you might want to spend more time resolving a bug to learn about the systems you’re tasked with maintaining then I’m at a loss sorry.
And then as experience developer you would have to try one of the other tools in your toolbox. Why should someone tie a hand behind their back and not use an LLM out of some sense of nerd pride?
Did you miss this part?
That's why he should spend 6 hours on it, and not give up and run to the gym. That's like saying "I shouldn't spend an hour at the gym this week, lifting weights is hard and I want to watch TV. I'll just get my forklift to lift the weights for me!"With his experience, I seriously doubt that he is trying to compete in the job market based on his ability to “codez real gud”. At his (and my) experience level he is more than likely going to get his next job based on a higher level of “scope” and “impact” (yes I’m using BigTech promo docs BS).
how about the whole thing was written by an AI as satire, mocking human "coding retreat"
[flagged]
Please don't cross into personal attack on HN. You can make your substantive points without that.
I did things the old way for 25 years and my carpal tunnels are wearing out. LLMs let me produce the same quality I always have with a lot less typing so not mad at that at all. I review and own every line I commit, and feel no desire to go back to the old way.
What scares the shit out of me are all these new CS grads that admit they have never coded anything more complex than basic class assignments by hand, and just let LLMs push straight to main for everything and they get hired as senior engineers.
It is like hiring an army of accountants that have never done math on paper and exclusively let turbotax do all the work.
If you have never written and maintained a complex project by hand, you should not be allowed to be involved in the development of production bound code.
But also, I feel this way about the industry long before LLMs. If you are not confident enough to run Linux on the computer in front of you, no senior sysadmin will hire you to go near their production systems.
Job one of everyone I mentor is to build Linux from scratch, and if you want an LLM build all the tools to run one locally for yourself. You will be way more capable and employable if you do not skip straight to using magic you do not understand.
> It is like hiring an army of accountants that have never done math on paper and exclusively let turbotax do all the work.
It's not though. It's fundamentally different because TurboTax will still work with clear deterministic algorithms. We need to see that the jump to AI is not a jump from hand written math to calculators. It's a jump from understanding how the math works to another world of depending on magic machines that spit out numbers that sort of work 90% of the time.
Imagine if Math calculators were just subtly wrong some percentage of the time for use cases that people use dozens or hundreds of times a day. If you could punch in the same math formula 100 times and get more than 1 answer on a calculator, most people wouldn't trust those for serious work.
They probably wouldn't think that the calculator makes them faster either
If calculators did work that way, I'm afraid that people would nevertheless take them up because "it saves so much time", and would develop fancy heuristics to plausibility-test for errors.
From what I remember, typical new C++ debugged code speed is about 20-25K lines per year, lines that are non-blank, non-comment and not completely verifiable by compiler. E.g., standalone bracket or comma or semicolon are not lines of code, function header is too not a line of code, but computation, conditions and loops are. This is from old IBM statistics, I learned about it circa 2007.
If we assume that there are 50 weeks per year, this gives us about 400-500 lines of code per week. Even at long average 65 chars per line, it goes not higher than 33K bytes per week. Your comment is about 1250 bytes long, if you write four such comments per day whole week, you would exceed that 33K bytes limit.
I find this amusing.
LOL. If you look at their comment history, they sure are typing a lot of characters for their wrists.
Yes, I checked their history of comments before posting. It made me confident that I hit the right note.
My software engineering experience longs almost 37 years now (December will be anniversary), six-to-seven years more than Earth's human population median age. I had two burnouts through that time, but no carpal tunnel syndrome symptoms at all. When I code, I prefer to factor subproblems out, it reduces typing and support costs.
I find it much more valuable to exchange ideas with humans than type every curl bracket and common boilerplate pattern and debug commit myself.
That said, I am also actively experimenting with VTT solutions which are getting quite good.
Most of the commentators here are bots these days anyways.
> If you have never written and maintained a complex project by hand, you should not be allowed to be involved in the development of production bound code.
So only the old hands allowed from now on, or how are we going to provide these learning opportunities at scale for new developers?
Serious question.
Junior developers have always been a lot less effective than senior developers. We will need new senior developers so we will need to train junior developers. Maybe we train them by forcing them to do things the hard way. The slow way. By hand. Because if we let them do things the fast way they are going to cause some serious damage.
Who's going to be doing that?
Employers were already refusing to hire juniors, even when 0.5-1 years' salary for a junior would be cheaper than spending the same on hiring a senior.
They'll never accept intentionally "slower" development for the greater good.
> They'll never accept intentionally "slower" development for the greater good.
That comes post Chernobyl.
internships for one.
my last summer intern did everything the manual way, except for a chunk where I wanted him to get something done fast without having to learn all the underlying chunks
The same way I learned 25 years ago still works today. Volunteer on open source projects.
Always happy to mentor people at stagex and hashbang (orgs I founded).
Also being a maintainer of an influential open source project goes on a resume, and helps you get seen in a crowded market while boosting your skills and making the world better. Win/win all around.
Can't disagree, that's how I did it too :-)
Even by pessimistic progress projections AI will be better than most at coding before this is a long term issue. And the output multiplier I'm seeing I suspect the number of SWEs needed to achieve the same task is going to start shrinking fast.
I don't think SWE is a promising career to get started in today.
There’s certainly a lot of uncertainty.
But pro-AI posts never seem to pin themselves down on whether code checked in will be read and understood by a human. Perhaps a lot of engineers work in “vibe-codeable” domains, but a huge amount of domains deal with money, health, financial reporting, etc. Then there are domains those domains use as infrastructure (OS, cloud, databases, networking, etc.)
Even where it is non-critical, such as a social media site, whether that site runs and serves ads (and bills for them correctly) is critical for that company.
But you have to be good at SWE to be good at security engineering and sysadmin, and the demand there is skyrocketing.
We have a completely broken internet with almost nothing using memory encryption, deterministic builds, full source bootstrapping, secure enclaves, end to end encryption, remote attestation, hardware security auth, or proper code review.
Decades of human cognitive work to be done here even with LLM help because the LLMs were trained to keep doing things the old way unless we direct them to do otherwise from our own base of experience on cutting edge security research no models are trained on sufficiently.
im not convinced that it will.
you dont notice it when you are only looking at your own harness results, but the llm bakes so very much of your own skills and opinions into what it does.
LLMs still regurgitate a ton.
Perhaps at some point, but tokens are expensive and the major providers are burning through cash.
I suppose it's like bandwidth cost in the 90s. At some point, it becomes a commodity.
> It is like hiring an army of accountants that have never done math on paper and exclusively let turbotax do all the work.
That is exactly been the situation for years. Once graduated accountants are not doing maths. They are using software (Exel, Xero etc.). They do need to know some basic formulas eg. NPV.
What they need to know is the law, current business practices etc.
> LLMs let me produce the same quality I always have with a lot less typing
If that's true, then you likely used to produce slop for code. :-(
> I did things the old way for 25 years and my carpal tunnels are wearing out.
You wrote so much code as to wear out your carpal tunner? Are you sure it isn't the documentation and the online chatter with your peers? :-(
... anyway, I know it's corny to say, but - you should have, and shoudl now, improve the ergonomics of your setup. Play with things like the depth of your keyboard on your desk, the height of the chair and the desk, with/without chair handrests, keyboard angle, etc.
> Job one of everyone I mentor is to build Linux from scratch
"from scratch" can mean any number of things.
> If that's true, then you likely used to produce slop for code. :-(
Local models are quite good now, and can jump right in to projects I coded by hand, and add new features to them in my voice and style exactly the way I would have, and with more tests than I probably would have had time to write by hand.
Three months ago I thought this was not possible, but local models are getting shockingly good now. Even the best rust programmers I know look at output now and go "well, shit, that is how I would have written it too"
That is a hard thing to admit, but at some point one must accept reality.
> anyway, I know it's corny to say, but - you should have, and shoudl now, improve the ergonomics of your setup. Play with things like the depth of your keyboard on your desk, the height of the chair and the desk, with/without chair handrests, keyboard angle, etc.
I already type with colemak on a split keyboard with each half separated and tented 45 degrees on a saddle stool, with sit/stand desk I alternate. I have read all the research and applied all of it that I can. Without having done all that I probably would have had to change careers.
> "from scratch" can mean any number of things.
As far as I know I was the first person alive to deterministically build linux from 180 bytes of machine code, up to tinycc, to gcc, to a complete llvm native linux distribution.
When I say from scratch, I mean from scratch. Also, all of this before AI without any help from AI, but I sure do appreciate it to help with package maintenance and debugging while I am sleeping.