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'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.
Doing this exact same process interactively with other people, and a not to NOT ERASE or later taking a picture of the whiteboard with your phone.
Same with notes that you will never see again. Done in pen, on random pages.
That process is bulletproof, for me.
All this to say that it is extremely useful to have the program and the problem space in your head and to be able to reason about it before hand. It makes it clearer what you expect and easier to catch when something unexpected happens.
Then with each year grow more paranoid if there are no bugs or typos.
That includes experimentation.
As a sort of an adjacent point, I worked through a book that is used on a course often called "from nand to Tetris". It is probably the best thing I've done, in terms of understanding how computers, assemblers and compilers work
I am not sure whether the statement is correct; I am not sure whether the statement is incorrect either. But I tested many editors and IDEs over the years.
IDEs can be useful, but they also hide abstractions. I noticed this with IntelliJ IDEA in particular; before I used it I was using my old, simple editor, and ruby as the glue for numerous actions. So when I want to compile something, I just do, say:
run FooBar.java
Conveniences sometimes make things more complicated in the long run, and I worry that code agents (the ultimate convenience) will lead to a sort of ultimate carelessness that makes our jobs harder.
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.
But a few hours (or days) in, I forget what the problem was. A part of my brain wakes up. I start thinking about what I'm passing around, I start recognizing the types from the context and names...
It's just a different way of thinking.
I recognized the same feeling after vibe coding for too long and taking back the steering wheel. I decided I'd never let go again.
My best LLM written code is where I did a prototype of the overall structure of the program and fed that structure along with the spec and the goal. It is kind of the cognitive bitter lesson, the more you think the better the outcome. Always bet on thinking.
Refactoring is a nightmare, as as types don't exist, the compiler can't help you if you try to access a property that doesn't exist.
I think generally people have realised this, and there are attempts to retrofit types onto dynamically typed languages.
Same reason my views about GC evolved from "it's for people lacking rigour" to "that's true, but there's a second benefit: no interleaving of memory handling and business logic to hurt clarity".
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++.
If you're prepared to forgo some portability and pick an architecture assembly opens up a lot if options. Things like coroutines, automatic SIMD become easier to implement. It's also got amazing zero cost C FFI (and I'm only half joking). Linux kernel booting into a minimal STC Forth is a lot of fun.
Not to mention you can run your code on android without SDK or NDK over ADB (in the case of aarch64).
Or....
Ctrl-Z
One of the continuous battles I kept loosing when introducing an assembly language undergraduate course. Other higher up colleages and deans would say... too hard... nobody uses that anymore... and shut the course down. But I would always sneak it into other courses I taught, systems programming, computer languages, computer architecture. But I've always felt there was a hole in my student's understanding of computers.
I grew up in a time when assembly language was a part of the cariculum. It helped bridge the gap between higher level languages like C/C++ ...etc. Also why certain language features exist. Also how many language constructs work. Also more importantly, as pointed out by the two posters above, it gives you a way to think about the CPU one asm line at a time what is going on the CPU ecosystem. That is fantastic training!
Even though I kept loosing the assembly language course battles, I hope I planted enough seeds in students that they will take it up on their own at some point. Everyone should at least learn to program in one assembly language.
As someone that used to write C and Assembly programs on a sheet of paper for university exams, I chuckled a bit. I finished university in post-soviet country twenty years ago or so and this was the norm. I used to hate it so much.
When I built my first guitar I had very few tools so I used what I had since I'm cheap ;) Then I bought better tools and it made my life a lot easier. But I got some lessons from the experience. Mostly though it was a pain that's solved by better tooling.
Spaces are sometimes mandatory sometimes not. Something I didn't even think might be confusing, for me it's like breathing.
Contrasting that to helping a college roommate with Arduino code he said he didn't understand what it was doing: he had 0 indentation. Braces everywhere. He didn't understand what it was doing not because it was complex logic (it was only maybe 30 simple lines) but because his flow control was visually incomprehensible. It's pretty hard to do that in Python.
But that's why I believe in polygloty. Best of multiple worlds.
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.
scaring people away w x86 cruft right out the gate is no good for anyone :-)
For example, I suspect more startups die from over-analysis than from acting too quickly and breaking things beyond repair.
That said, I think LLMs can be a mixed bag here. I find that they can really help my analysis phase, by suggesting architectures, finding places where future abstractions will leak, reminding me of how a complex project works, etc. I’ve found it invaluable to go back and forth in a planning phase with an agent before even deciding what exactly I want to build, or how.
And on the implementation side, they make code attempts very cheap, so I can try multiple things and just throw them away if I don’t like the result.
But that said, I do find that it requires discipline, because it’s very easy to get into a groove where I don’t do any of that, and instead just toss half-baked ideas over the wall and the agent figure out the details. And it will, and it’ll be pretty decent usually, but not as good as if I pair program with it fully.
My understanding is that was the actual point of "move fast and break things" - gain knowledge by trying stuff to help you make better decisions, even if you make a mistake and need to roll back or fix it. The art to this is figuring out how to contain the negative consequences of whatever you're testing, but by all means, experiment early to gather information.
I've stated it to mentees as "don't be afraid to start a fire as long as you know where the fire extinguishers are" - it's OK to fail in the service of learning so long as you fail in a contained way.
1. There's a right answer to every problem in school
2. If you got it wrong, that's bad, and you did bad.
The pattern I've seen from younger people these days is a learned helplessness, where there's no room for them to be creative in school, and any attempt to do so runs the risk of failing an assignment, getting a B, missing out on Harvard, and spending the rest of their lives poor in a ditch, or so they're told.
I'm pretty skeptical that using a line editor will have helped them learn. It probably helped them memorise their code but is that really learning? Dubious.
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).
This is bogus. If you think LLMs write less buggy software, you haven't worked with seriously capable engineers. And now, of course, everyone can become such an engineer if they put in the effort to learn.
But why not just use the AI? Because you can still use the AI once you're seriously good.
I hope if/when diffusion models get a little more traction down the line it'll put some new life into autocomplete(-adjacent) workflows. The virtually instantaneous responses of Inception's Mercury models [0] still feel a little like magic; all it's missing is the refinement and deep editor integration of Cursor.
On the subject of diffusion models, it's a shame there aren't any significant open-weight models out there, because it seems like such a perfect fit for local use.
When I let an agent write too much of the structure, the code may work, but a week later every small change starts with "where did it put that?"
I agree with the premise of the article but I just don't think going back to manual coding is the solution.
Here's my new attempt using puzzle as an analogy which I wrote yesterday:
Starting last year, I noticed coding was getting less fun. It’s like buying a puzzle set and finding out there’s an auto-complete button. Press it and the puzzle solves itself. Faster than me, better than me, prettier than me. It’s like playing a game with cheats on.
I don’t even have to touch the pieces anymore. I just tell the auto-solver what I want. Tell it I want a bird, it gives me a bird. A pirate ship? Here’s a pirate ship. At first I never imagined it could do a rocket, but with its help, that went from fantasy to reality fast.
Sometimes it doesn’t quite match what I wanted, but usually just telling it what’s wrong fixes things. The whole process is so fast that, if nothing’s broken, I don’t even bother looking at how it actually solved it. That would just waste time.
But coding felt less fun with this new assist mode.
The fun of puzzle-solving is gone. That feeling of trekking through the hard parts and finally reaching the summit is gone. Now it’s like taking a cable car up.
Before, I had to think alone for a long time, try things, experiment, until I finally cracked the problem. Now with the assist mode, it’s like doing college homework where the teacher already has the answer key. I just ask and I get a standard answer.
Coding went from craft to management. “I” went from a craftsman with standards to a foreman watching workers do the job. It’s just not the same. And “foreman” sounds kind of weak.
Yes, AI unlocks coding for people who fail FizzBuzz. This isn't really relevant to making software though.
I usually code faster with good (next-edit) autocomplete then writing a prompt and waiting for the agent.
This is like saying "EV charging is soooo slooooow" and thinking you need to stand next to the car holding the nozzle in the charging port like with a petrol car.
Of course you go do something else unless it's a literal 30 second operation.
I think most people "moved on" because they both thought the agent workflow is cooler and were told by other people that it works. The latter was false for quite some time, and is only correct now insofar that you can probably get something that does what you asked for, but executed exceedingly poorly no matter how much SpecLang you layer on top of the prompting problem.
> Everyone moved on
> it is not a useful interface
You've made three claims in your brief comment and all appear to be false. Elaborate what you mean by any of this?
In some codebases, autocomplete is the most accurate and efficient way to get things done, because "agentic" workflows only produce unmaintainable mess there.
I know that because there are several times where I completely removed generated code and instead coded by hand.
I just wish I knew of a good Emacs AI auto complete solution.
For me it was GW-BASIC and no editor as we know them today.
That was instant gratification, rapid development, no silly layers. It was pretty pure. It is what hooked me.
In a sense, agentic coding, has brought back the excitement to building software for me because I don’t have to wrangle all the crazy enterprise or other modern development considerations directly. There’s a closer connection between thought and result, which is what was the magic that captured my imagination.
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.
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.
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.
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.
You hit on a very important point here. The linked AGENTS.md is a bad idea for general purpose use because the things it's meant to tackle, including an inherent bias towards or against DRY, is one of the big differences between model families. GPT 5.4 Codex has a very different "coding personality" from Claude Opus.
It's a product of whatever model it was tested on.
I can't do it. If I let an LLM write code for me, that code is untouchable. I see it as a black box, that I will categorically refuse to open. If it works, I use it, but don't trust it. If it breaks, I get frustrated. The only way that works for me is me behind the driving wheel at all times and an LLM as an assistant that answers my questions. We either brainstorm something or it helps me express things I know in languages syntax. Somehow that step has always been a bit of a burden for me - I understood the concepts well, but expressing them in syntax was a bit of a difficulty.
I appreciate that the author understands why doing everything "the old way" is good. AI is a tool, it can't be a replacement for how you think and it can't be a replacement for the actual work.
I wish more people had a desire for the inner workings of things because it makes you better at actually using tools. Implementing compilers, databases, OSes, control systems, etc. is like practicing swimming. Yeah, you might not ever swim again but when you need to the muscle memory will be there when you need to get out of the ocean (I know this is a strained metaphor).
Knowing more can only be a boon to using LLMs for coding and it's really a general problem in ML. I work in a science field as hw / sw engineer and I've seen so many pure data science people say they can replace all our work with a model, flail for 2 years and then their whole org gets canned. If they just read a textbook or collaborated (which they never do, no matter how polite you are), they'd have been able to leverage their data science skills to build something great and instead they just toil away never making it past step 0.
The shark is being jumped.
When Jensen Huang says you need to spend $500k on tokens per developer per year he knows it will be perceived as bullshit, but by setting such a high he's subtly making spending $0 seem abnormal and irrational.
This article does the same thing.
It's the same reason most companies have an ultra deluxe $150 /month plan nobody buys.
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.
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.
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.
Do they? Did you write them? If not, how do you know they confirm the desired behavior? If your tests are AI generated (and not human reviewed) then even if you're doing spec-driven development and provide a comprehensive spec, how can you be sure the tests actually test the desired behavior?
Now if you're either writing or reviewing the tests, then sure.
Also, for what it's worth, when I talk about my "responsibility" I'm speaking more from a self-imposed sense of... um, almost a moral responsibility I feel, not something involving a 3rd party like a customer or employer.
There is no “morality” when it comes to my job. Outside of my feeling morally obligated to give my employer the benefit of all my accumulated skills for 40-45 hours a week in exchange for the money (and in a previous life RSUs) in my account.
I feel accountable to my coworkers and customers to deal with them fairly and honestly.
What other moral obligation should I have besides my employer, coworkers and customers?
When I use SAML, I still have to check that the user has some sort of attribute that indicates that access was granted to the application. If this access rule is defined outside the application, then why bring up Claude? If it isn't then Claude is responsible for implementing the access rule, which means the comment is 100% wrong.
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’m very concerned about how the next generation of software engineers will pick up deep knowledge about this stuff, if at all.
I also expect a bunch of open source/open core projects to go closed source in the next few months.
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’ve spent a lifetime teaching myself programming, computers, and engineering. I have no formal education in these disciplines and find that I excel due to the self-taught nature of my background.
I take a very metered approach to AI and use it for autocomplete while still scrutinizing every token (not the AI kind) as well as an augment to my self-pedagogy. It’s great to be able to “query” or get a summary from a set of technical documents on demand.
However, I don’t understand the desire to remove oneself from the process with AI. I simply don’t do anything that won’t teach me something new or improve my existing skills.
There’s more to engineering than simply programming. Both the engineer and the intended user base must also understand the system. The value lost is greater than the sum of all the parts when an LLM produces most or all of the code.
Not trying to be rude but you either must not be a professional software engineer or your skill level isn't that high yet. You simply cannot always do things that teach you new skills or improve existing ones. In any sufficiently complex project, even the most novel ones, you'll do things you've done many times before.
My last job started with "here's a book about go programming." 2 years later I was learning FastAPI. Now I'm programming in C again but I have spent most of my time learning about git actions and writing SCCS->git conversion software. I've never used SCCS before.
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.
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.
Unless you can swing a six week sabbatical and return to your current job
> One solution to this constant companion problem: Spend more time with your phone out of easy reach. If it’s not nearby, it won’t be as likely to trigger your motivational neurons, helping clear your brain to focus on other activities with less distraction.
Reminds me of this study: "The mere presence of a smartphone reduces basal attentional performance"
The effect persisted even when the phone was switched off. It only went away when the phone was moved to a different part of the building.
fine, but the gym analogy breaks down somewhere. in a gym, the person who actually lifts heavier gets noticed. in software, the person with the right bio and the right network gets noticed, regardless of whether they've ever lifted anything real.
you can spend three years learning compilers properly and have a handful of readers. someone else ships a wrapper on a saturday and lands a pmarca quote tweet by monday.
coding the old way is good for you. i'm not convinced it's what gets you noticed. the strain was never really what got rewarded in the first place.
> coding the old way is good for you. i'm not convinced it's what gets you noticed.
You won’t go completely unnoticed if you’re good at your job but you can only be noticed from your deliverables, which is a slow process. You can buff up your presence by talking about it a lot, yes, but you won’t get 0 attention for hard work.
My ex business partner said “AI won’t take your job, but the person who uses it will”. I don’t agree. The person who isn’t reliant on AI is the one you should really be afraid of.
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'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.
They probably wouldn't think that the calculator makes them faster either
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.
In what way? You're either very young or very old, right? Voice-to-text has been a common way to input text online since iPhone. Someone commented on HN != they typed that many words with their fingers.
If the person I replied do use voice-to-text, their mention of carpal syndrome is moot and this is amusing. If they do not use voice-to-text, it is still amusing in the sense of my previous comment.
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.
That said, I am also actively experimenting with VTT solutions which are getting quite good.
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.
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.
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.
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.
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.
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.
I suppose it's like bandwidth cost in the 90s. At some point, it becomes a commodity.
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.
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.
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.
If you mean this kind of from scratch:
https://www.bootstrappable.org/
then - that's both impressive and important, and I salute you!
sadly the discussion steeply diverges IMHO -- rote work by defined spec in highly defined API environment is absolutely a thing, while abstracted and/or original ideas on a platform of choice with substantial new or custom work implementation, is different.
The old way?! So not using AI is already being called "the old way"?!!
That statement sends alarm bells off about writing on the internet and trust to be put into it as if I'm the first one to notice it.
Recently I’ve been trying to combat this by learning things “deeper” IE. yes I can secure and respond to container based threats but how do containers actually work deep down?
So far I think it’s working well and as an odd plus it’s actually helping me use AI more efficiently when I need to.
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?
Maybe there’s another way…
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.
the old way which is about one year ago?
I remember writing BASIC on the Apple II back when it wasn't retro to do so!
Typing and thinking in English is demonstrably slower than in code/the abstract (Haskell for me.)
And no, I didn't write English plans before AI. Or have a stream of English thought in my head. Or even pronounce code as I read and wrote it. That's low-skill stuff.
I tried LLMs because of AI fomo by my CEO. "Opus 4.whatever is a stepwise improvement - I am convinced all coders who don't go all-in on AI will be obsolete soon." Multiple times I tried. Every time Claude creates crap and I have to spend a bunch of time correcting it in a loop. Or basically scripting it. And it's like..I never spent this much time thinking or actively working before.
So I'm back to being natty and I am delivering more and have more time during the workday to spend with my wife and kid and video games etc.
> 15 years of Clojure experience
My God I’m old.
1. It increases the chances of any bugs being found and resolved.
2. It encourages the author to be more careful with their code to avoid long reviews with a lot of findings.
3. It ensures at least two people - the author and approverd - have familiarity with the code.
4. It spreads responsibility for the code across at least two people - the author and approvers.
It's clear this article's author does not review their own code. I sure hope that code is not used for anything important.
> 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.
Though a lot of the time this is more an inefficiency of the documentation and Google rather than something only LLMs could do.
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.
* 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!
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.
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?
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.
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 euphoria I felt after fixing bugs that I stayed up late working on is like nothing else.
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.
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.
On the other hand, while I notice people not being impressed, they are careful to shift difficult things off onto others if at all possible.
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.
This is both a strawman and a false dichotomy.
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.
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.
For haystack-style debugging (searching logs, grepping stack traces), a fast cheap model with large context (Gemini Flash, Claude Haiku) is more cost-effective than a frontier model. For the conceptual fault category you mention — where you actually need to reason about system design — that's when it might be worth paying for o3/Claude Opus class models.
The friction is that most people default to whatever chatbot they have open, rather than routing to the right tool. The agent/LLM tooling space has gotten good enough that this routing is automatable, but most devs haven't set it up yet.
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.
If you’re experienced as you are, you’re not learning the same way a junior assigned this might learn from it.
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
But he was doing this for education, not for work.
This is exactly how you learn to create better abstractions and write clear code that future you will understand.
But in my long career even the smartest most experienced software engineers I’ve met m write their share of crazy abstractions from hell.
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.
(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 mean the way that the majority of code is still written by professionals?
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.
How? I just open multiple terminal panes, use git tree, and then basically it’s good old software dev practices. What am I missing?
I was asking if there was something about the “agentic” part in particular that was difficult.
Claude Opus is going to give zero fucks about your attempts to manage it.
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 good stuff, there’s no alternative but to know and to have taste. Llms change nothing.
Shouldn't they be the people making the most substantial, artisanal, sweat-of-the-brow deep-thought comments?
Citation needed.