"It’s easy for long-term strategic, high-impact work to sink to the bottom of everyone’s todo list."
"[...] But one where the tasks to accomplish the project are not anyone’s full-time job."
Sounds like the organization's leadership are incapable of balancing short term and long term goals, and it's falling to people who are paid less to "step up" and try to swim against the current for the good of the company.
or
Whatever the author is talking about is some engineering pipe dream disconnected from actual business value, and someone is dragging a bunch of other people semi-willingly along trying to execute on it without a mandate/funding from leadership.
Impossible to say which from the outside. But I've known several instances of both cases.
That’s basically the face of GMOs, so it is an issue for GMOs. GMOs for whatever reason have a terrible ambassador and I haven’t seen evidence to the contrary.
For vaccines, a good portion of the population remember vaccines being developed and marketed to help people. Then there are immigrants that remember more recently how life changing vaccines are.
On the contrary, I find "The older I get, the more I appreciate dynamic languages. Fuck, I said it. Fight me." is exactly my sentiment too, with a caveat. I really like gradual typing, like python has. And not like ruby has (where it's either RBS files and it's tucked away, or it's sorbet and it's weird).
The worst code base I had to work in by far was a Python code base. Extremely difficult to refactor. Many bugs that were completely avoidable with static typing. I think maybe more modern Python is a little bit better but wouldn't be my choice for large projects. It's not just about correctness. It's also about performance. That code was so slow and that impacted our business.
Meanwhile the worst codebase I've had to work in by far is golang where someone clearly took the language's limitations as a challenge and not as an intentional constraint on writing clever code. And it's an impressive feat because I too have seen horrifying clusterfucks of python codebases with no typing whatsoever and very sloppy hygiene.
My take on static vs dynamic is that a sufficiently motivated programmer can make a mess out of anything they're given, and that types actually really don't help that much. Furthermore, "the types work out!" is also not actually an incredibly comforting fact to me. There are so many more places things can be wrong. And I also find that the types of errors static typing prevents tend to not be the most meaningful errors to prevent or the hardest to catch in subsequent testing, ESPECIALLY with gradual typing!
With python in particular, gradual typing with a checker gets you 99% of the benefits of static typing, with the HUGE added benefit of you just being able to tell the type checker to stfu when it's not adding value. ORMs and data parsing are so much easier in dynamic languages, for instance. And I find the most ergonomic ORMs and data parsers in static languages tend to be the ones that have gone to extraordinary lengths to make them feel like the stuff you just get much more cheaply in dynamic languages. I have recently been writing python with basedpyright and very intentional type hinting and it has been my favorite experience in a long time. More impactful to my productivity (real productivity - actually producing things that work and are real) than AI.
There's almost no point in arguing about this anymore. Neither you nor the other person are going to be convinced. We just have to wait and see if a new crop of 100x productivity AI believer companies come along and unseat all the incumbents.
I'm deeply convinced that there's 2 reasons we don't see real takes like this: 1) is because these people are quietly appreciating the 2-50% uplift you get from sanely using LLMs instead of constantly posting sycophantic or doomer shit for clout and/or VC financing. 2) is because the real version of LLM coding is boring and unsexy. It either involves generating slop in one shot to POC, then restarting from scratch for the real thing or doing extensive remediation costing far more than the initial vibe effort cost; or it involves generally doing the same thing we've been doing since the assembler was created except now I don't need to remember off-hand how to rig up boilerplate for a table test harness in ${current_language}, or if I wrote a snippet with string ops and if statements and I wish it were using regexes and named capture groups, it's now easy to mostly-accurately convert it to the other form instead of just sighing and moving on.
But that's boring nerd shit and LLMs didn't change who thinks boring nerd shit is boring or cool.
> because the real version of LLM coding is boring and unsexy
Some people do find it unfun, saying it deprives them of the happy "flow" of banging out code. Reaching "flow" when prompting LLMs arguably requires a somewhat deeper understanding of them as a proper technical tool, as opposed to a complete black box, or worse, a crystal ball.
There’s also just the negative association factor.
I use LLMs in my every day work. I’m also a strong critic of LLMs and absolutely loathe the hype cycle around them.
I have done some really cool things with copilot and Claude and I keep sharing them to within my working circle because I simply don’t want to interact that much with people who aren’t grounded on the subject.
I would be interested to hear your take on Copilot vs Claude. I have used Copilot (trial) in VS Code and I found it to mostly meet my needs. It could generate some plans and code, which I could review on the go. I found this very natural to me as I never felt 'left behind' in whatever code the AI was generating. However, most of the posts I see here are on Claude (I haven't tried it) and very few mentions of Copilot. What is your impression about them and the use cases each is strong in?
(Context: I'm a different person, but have thoughts on this)
I started using Copilot at work because that's what the company policy was. It's a pretty strict environment, but it's perfectly serviceable and gets a lot of fresh, vetted updates. IDE integration with vs code was a huge plus for me.
Claude code is definitely a messier, buggier frontend for the LLM. It's clunkier to navigate and it has much more primitive context management tools. IDE integration is clunky with vs code, too.
However, if you want to take advantage of the Anthropic subscription services, I've found Claude Code is the way to go... Simply because Anthropic works hard to lock you into their ecosystem if you want the sweet discounts. I'm greedy, so I bit the bullet for all of the LLM coding stuff I do in my personal life.
Copilot isn’t really a competing product to Claude - in fact I use Claude through copilot.
I have found in general that for the type of work I do (senior to staff level engineering, 90-10 research to programming) that Claude Opus is the only model really worth my time - but I just really like the Copilot CLI tooling.
I do use LLMs to learn about new subjects but we already only bill 10% for "coding" and that's inflating it to cover other parts.
I can't imagine that slopping it up would be a great decision. Having alien code that no one ever understood between a bug report and a solution. Anthropic isn't going to give us money for our lost contracts, is it?
I would say I'm using it for about half of the "10%" and and a quarter of the "90%".
> I can't imagine that slopping it up would be a great decision. Having alien code that no one ever understood between a bug report and a solution. Anthropic isn't going to give us money for our lost contracts, is it?
Absolutely, that's a real concern. The only time I will let it loose on something is a throwaway project to test something, or a small tool that I know I can write deterministic tests for.
On codebases of any significant size, I'm using it more like a custom domain Stackoverflow search engine.
Software engineering is only about 20% writing code (the famous 40-20-40 split). Most people use it only for the first 40%, and very succesfully (im in that camp). If you use it to write your code you can theorettically maybe get 20% time improvement initially, but you loose a lot of time later redoing it or unraveling. Not worth bothering.
20% is one of those cool lies SWEs have been able to push through (like “our jobs are oh so very special we can’t really estimate it, we’ll create an entire sub-industries with our industry to make sure everyone knows we can’t estimate”).
SWEs spend 20% of the time writing code for exactly the same reason brick-layers spend 20% of their time laying bricks
- A lot of research. Libraries documentation, best practice, sample solutions, code history,... That could be easily 60% of the time. Even when you're familiar with the project, you're always checking other parts of the codebase and your notes.
- Communication. Most projects involve a team and there's a dependency graph between your work. There may be also a project manager dictating things and support that wants your input on some cases.
- Thinking. Code is just the written version of a solution. The latter needs to exists first. So you spend a lot of time wrangling with the problem and trying to balance tradeoffs. It also involves a lot of the other points.
Coding is a breeze compared to the others. And if you have setup a good environment, it's even enjoyable.
It can be any number of things. From spending hour or two just writing requirements, to giving an example of existing curated code from another project you wrote and would like to emulate, or rewriting existing apps in a different language/architecture (sort of like translating), to serving as a QA agent or reviewer for the LLM agent, or vice versa.
I kinda like how you can just use it for anything you like. I have bazillion personal projects, I can now get help with, polish up, simplify, or build UI for, and it's nice. Anything from reverse engineering, to data extraction, to playing with FPGAs, is just so much less tedious and I can focus on the fun parts.
I think we'll get there. We need to get at least some AI bust going first though. It's impossible to talk sense into people who think AI is about to completely replace engineers, or even those who think that, while it might not replace engineers, it's going to be doing 100% of all coding within a year. Or even that it can do 100% of coding right now.
There's a couple unfortunate truths going on all at the same time:
- People with money are trying to build the "perfect" business: SaaS without software eng headcount. 100% margin. 0 Capex. And finally near-0 opex and R&D cost. Or at least, they're trying to sell the idea of this to anyone who will buy. And unfortunately this is exactly what most investors want to hear, so they believe every word and throw money at it. This of course then extends to many other business and not just SaaS, but those have worse margins to start with so are less prone to the wildfire.
- People who used to code 15 years ago but don't now, see claude generating very plausible looking code. Given their job is now "C suite" or "director", they don't perceive any direct personal risk, so the smell test is passed and they're all on board, happily wreaking destruction along the way.
- People who are nominally software engineers but are bad at it are truly elevated 100x by claude. Unfortunately, if their starting point was close to 0, this isn't saying a lot. And if it was negative, it's now 100x as negative.
- People who are adjacent to software engineering, like PMs, especially if they dabble in coding on the side, suddenly also see they "can code" now.
Now of course, not all capital owners, CTOs, PMs, etc exhibit this. Probably not even most. But I can already name like 4 example per category above from people I know. And they're all impossible to explain any kind of nuance to right now. There's too many people and articles and blog posts telling them they're absolutely right.
We need some bust cycle. Then maybe we can have a productive discussion of how we can leverage LLMs (we'll stop calling it "AI"...) to still do the team sport known as software engineering.
Because there's real productivity gains to be had here. Unfortunately, they don't replace everyone with AGI or allow people who don't know coding or software engineering to build actual working software, and they don't involve just letting claude code stochastically generate a startup for you.
> Or even that [AI] can do 100% of coding right now.
I don't actually think the article refutes this. But the AI needs to be in the hands of someone who can review the code (or astrophysics paper), notice and understand issues, and tell the AI what changes to make. Rinse, repeat. It's still probably faster than writing all the code yourself (but that doesn't mean you can fire all your engineers).
The question is, how do you become the person who can effectively review AI code without actually writing code without an AI? I'd argue you basically can't.
> The question is, how do you become the person who can effectively review AI code without actually writing code without an AI? I'd argue you basically can't.
I agree, and I'd go a step further:
You can be the absolute best coder in the world, the fastest and most accurate code reviewer ever to live, and AI still produces bad code so much faster than you can review that it will become a liability eventually no matter what
There is no amount of "LLM in a loop" "use a swarm of agents" or any other current trickery that fixes this because eventually some human needs to read and understand the code. All of it.
Any attempt to avoid reading and understanding the code means you have absolutely left the realm of quality software, no exceptions
It isn't as binary as that. We already don't read all the code. When was the last time you checked the disassembly/IR of the programs you wrote? Very few will say recently. The others, despite not reading the entirety of the code, can still produce something with good quality.
Besides, it's not like QA ends at code analysis. In fact, that's pretty shallow for the field.
My boss decreed the other day that we’re all to start maximising our use of agents, and then set an accordingly ambitious deadline for the current project. I explained that being relatively early in my career I’ve been hesitant to use any kind of LLM so I can gain experience myself (to say nothing of other concerns), and yeah in his words I’ve “missed the opportunity”
Unfortunately in the majority of organizations, the idiots are at the wheels. It's not people with actual experience of how engineers do things, that dictates what those engineers should do.
Interesting, we only have generic 'use AI' in our goals. Though its generic framing probably indicates more company's belief in this tech than anything else.
A lot of draft laws haven't been touched in a long time and aren't updated for modern gender politics. Though I do wonder if they'll actually get updated ever - no politician wants to touch it and it's not like anyone is screaming for the right to be forced to go die in war.
It's always weird to me how surprised women are that every single man they know has had to specifically, actually physically ink paper to sign up for the draft. It definitely feels weird/spooky when you do it, given the implications and that despite being compulsory it's not automatically done for you.
To clarify: every young person regardless of gender is legally obliged to go through fitness testing for conscription and if deemed suitable must go through it if selected. I imagine it’s roughly similar in Denmark?
Up until the fall of the USSR ~all men did go through conscription/basic military training. After the fall only the ones that wanted to and were selected did. Now it’s ramping up massively.
> and that despite being compulsory it's not automatically done for you.
I though it was weird that the United States had a requirement for people to physically sign a paper to do it. It looks like only this year they made it automated.
> Beginning on December 18, 2026, the Selective Service System will be required to identify, locate, and register all male (as assigned at birth) U.S. residents 18 to 26 years old on the basis of other existing federal databases. Men will no longer be required to register themselves or be subject to penalties for failing to do so. This was noted to be the most significant change to Selective Service since the self-registration system began in 1980.
both are already tied to residence registration (which is mandatory in germany, because it defines where you pay taxes). there is no need to register for the draft. it is automatic, once you turn 18 you get the letter to get tested if you qualify.
"[...] But one where the tasks to accomplish the project are not anyone’s full-time job."
Sounds like the organization's leadership are incapable of balancing short term and long term goals, and it's falling to people who are paid less to "step up" and try to swim against the current for the good of the company.
or
Whatever the author is talking about is some engineering pipe dream disconnected from actual business value, and someone is dragging a bunch of other people semi-willingly along trying to execute on it without a mandate/funding from leadership.
Impossible to say which from the outside. But I've known several instances of both cases.
reply