Practicing code specifically is one of many options for engineers right now. How about other skills? For example, now seems like a good opportunity to start developing deep knowledge in a particular domain, so that when you build AI assisted software in that space, you’re competent enough to know if it’s doing the right thing. Or, develop a better understanding of a range of disciplines, so that when you go to solve problems, you’re aware of them and have more areas to draw from. (The combination is what Valve calls a T-shaped employee I believe.) Also a good opportunity to develop your interpersonal skills.
> The combination is what Valve calls a T-shaped employee I believe
For what it's worth, I've heard this at jobs before, and I've never worked at Valve (or as far as I'm aware with anyone who worked at Valve previously). I think it's probably more common than just something they say.
I agree. I think the rapid learning generalist has a real advantage right now, but that kind of advantage cannot be leveraged by big companies structured to utilise specialists. I think that's why individual contributors in big teams aren't seeing massive benefits from AI where a small team or solo developer may be seeing greater leverage.
If you are a strong generalist with an entrepreneurial spirit, I think I would be aiming at getting hired by a small company where you can provide a buttload of value or looking at starting something where you have domain experience outside of software.
> I think that's why individual contributors in big teams aren't seeing massive benefits from AI where a small team or solo developer may be seeing greater leverage.
This rings true. It is the best time ever for small teams. A big team is potentially several smaller teams, so this can be a force multiplier for them too.
Another force multiplier for reorganizing larger teams, be willing to consider smaller teams starting with single contributors.
I think what I’m suggesting is: consider being more than just a software engineer. Become a software engineer with expertise in other fields. Or a software engineer AND a fluid simulation engineer. This might not make sense for someone who currently works at say a business SaaS company, but how much longer are those jobs going to be around?
But this is also a great time to be building your own business, in which case you may want to develop business related skills.
I had exactly this way of thinking last year and began specializing myself: github.com/glouw/ensim4
I reckon moving forward software will became an applied tool to the applied sciences. I mean, it always has been, but the barrier to entry has lowered for the easily verifiable, and that is programming, and not the problem being solved
Now is the time to practice following a horse pulling a plough, because soon all the other farm hands will forget the nuances of handling a plough manually and your skills will be sought after by those who want you to drive a tractor. Wait, what?
> Once you try the models, you realise how good they are, and there is the second incentive. These things write working code and as the models get better and better, the argument that they make mistakes will get quieter and quieter until it fades away, like all high conviction opinions that turn out to be wrong over time do.
Is this true though? Will the models get better and better? I'm not a hater, but Sonnet/Opus generates terrible code albeit mostly functioning code.
Totally agree. Especially for commercial or code that adds value. Writing code is just one element of developing quality, robust, software. In the rea world, commercial or production software must be maintained, supported, and must respond to changing user requirements. The human element is critical, unless you’re OK with relying on LLM’s, crossing your fingers, and have no care to support users.
This but unironically. Keep your mass-produced slop for yourself, show me what you have built with effort.
I spent two days learning about quaternions to fix a buggy spaceship moving in space, when an LLM could have done it for me in seconds. A great use of my time: now I understand quaternions and I have levelled up in my knowledge, which makes me more confident to tackle larger problems in this space.
Not offended and I find it funny, though you nailed my itching:
> "Veganism is a philosophy and way of living which seeks to exclude—as far as is possible and practicable—all forms of exploitation of, and cruelty to, animals for food, clothing or any other purpose; and by extension, promotes the development and use of animal-free alternatives for the benefit of animals, humans and the environment. In dietary terms it denotes the practice of dispensing with all products derived wholly or partly from animals."
My personal take is yes, assuming there's no animal exploitation or cruelty involved.
That said AFAIK there is no consensus: some abstain from all animal inputs while others focus on avoiding harm, which itself can be interpreted in different ways. It's more a philosophy than a rulebook, lab-grown meat kind of sits in a gray area. I'd be curious to try it :-)
Nice philosophical point. To iron-on more irony, zooming out a little, one could also argue much real historical experience was first erased when it was written down with the presumption of authority.
One great opportunity is for expert-developers to push the boundary of better algorithms or libraries. No one rolls out their own cryptographic library, majority problems faced in our systems are common. If that common problem is solved once and packaged into a library to be used by anyone, no one else needs to bother looking at it. Most of modern software dev is all about plumbing. The harder parts need to solved once and that solution becomes available to everyone immediately.
Yeah but in my opinion AI generated code is still pretty low to mid quality and can't push boundaries.
And as people rely more on it they sort of forget how to have unique ideas too.
While I agree with the outcome, I don't agree with reasoning. What really matters for larger projects isn't how quickly you can write code, but how easy it is to understand the code and the architecture to those modifying the specific part. And this is where exclusively relying on LLMs is a disservice to you in the end — while they are good at generating _plausibly looking_ code, it's typically quite flawed, but in a non-obvious way, which is often hard to catch even for senior engineers. Thus for longer term it's actually beneficial to write most of the critical code by hand, and only leave less important stuff to LLMs. What percentage should be left to LLMs highly varies between projects, so there is no single good number.
This article forgot the strongest argument for hand writing your code. When the process is done, you understand it at a depth far beyond any vibe coder who created the same thing
I think for a lot of people, the truth is they wanted an excuse to stop writing code and LLMs gave it to them. That's why the shift has been so violent and abrupt. The majority found what they were looking for. No appeal to logic or reason as to why total submission to the machine is a bad thing will register.
I don't know, when I started out as a web developer I met a hardcore C developer once and I was quite impressed about his low level knowledge, and wanted to eventually learn that too. But as time passed by the web world kept developping and becoming more interesting and eventually I want to make applications in the end. A few years later I saw the guy again and he told me he got into Ruby on Rails businesses, because there was a lot of work in there.
Is the purpose of this article to say "If you only do one thing, you will likely not excel at other things"? Is there anyone to which this is not an obvious conclusion? Did I miss the point?
I think you did. The argument (which may be wrong) is that agentic coding has a lower barrier to entry than hand-coding, and that since (barring AGI) there will remain a demand for hand-coding, that skill will become more valuable the more developers lose it, while agentic coding due to its lower barrier to entry will become less valuable.
It sounds like PHP and JavaScript all over again. The barrier was low and a lot of slop was produced by their users. Eventually due to huge demand, a lot of sophisticated things emerged (think V8, various frameworks, other browser gymnastics and evolving standards, etc).
The purpose of the article is to say that the skill of software engineering depends on the ability to write code by hand, even now that you don't necessarily have to on a day to day basis. If you don't keep in practice, the author thinks, you will become less effective even at driving agents than people who do.
Is that true? I'm not quite as confident as the author, but it seems plausible. I've seen a number of managers who used to write code try and fail to drive Claude as well as even the junior engineers reporting to them.
I know brain atrophy is mentioned a lot these days. But is anyone worried about early onset dementia? If we see a higher number of younger dementia patients needing care in the next few decades, once again it will be the next generation who will bear the burden just so the current generation can do the "lulz". Jesus tap-dancing Christ the job wasn't even that hard in the first place.
I think you'd have to start with 55+ years old and go upward to find an age range where more than 10% of programmers routinely wrote assembler code in their careers.
To find the same for machine code you'd need to start at 65 or older.
change that 10% to 0.5% and I would agree. i am 62, worked in low level coding and hw interfacing. 'routinely' not even; i would say on occasion, needed to look at a bit, or even more rare, had to write a bit (like a small module)
Curious, what do you normally use? I had to write a few timing sensitive MC drivers and the only way I knew how onto do that reliably was using assembly. But granted, it wasn't _often_, just more than I expected (especially for someone who doesn't normally do that low level stuff, this was for an art project)
sure. timing sensitive stuff. < 50 lines. jump back to C as soon as the critical stuff is over.
'performance stuff'. i try to solve it in C for a bunch of reasons; others readability is one. almost never need to do more than a short macro of assembly embedded in C.
the actual most use of have for assembly is "what is happening here.." and need to ask the debugger for the assembly for some deeper understanding.
Some years, did these things 5 times, so maybe 20 hours. Other years, never.
As far as "sit down and write some assembly to solve problem X", the answer is never. (except when X is right in the middle of the above items)
Really not the same. Assembly / machine code is entirely deterministic - they are a notation for your thoughts. LLM produced content is more a smorgasbord of other people's thoughts, and cannot help you with clarity, conviction, etc etc.
They meant to say that swithing from assembly to high-level programming is not the same as switching from high-level programming to LLMs, because the latter loses you the guarantee that the computer will do what you told it to.
Sure, it's less common that people are writing full-fledged applications in nothing but assembly.
However, I would strongly disagree that people are no longer writing/using assembly. I was writing a bit of assembly the other day, for example.
Come on over to the game emulation, reverse engineering, exploitation writing, CTF, malware analysis, etc. hobby spaces. Knowledge of assembly is absolutely mandatory to do essentially anything useful.
reply