I'm curious how many ICs are truly excited about these advancements in coding agents. It seems to me the general trend is we become more like PMs managing agents and reviewing PRs, all for the sake of productivity gains.
I imagine many engineers are like myself in that they got into programming because they liked tinkering and hacking and implementation details, all of which are likely to be abstracted over in this new era of prompting.
While I share your reservations, how many millions of people have experienced the exact same disruption to their jobs and industries because of software that we, software engineers, have created? It’s a bit too late, and a touch hypocritical, for us to start complaining about technology now it is disrupting our way of working in a way we don’t like.
We had to tinker piece by piece to build a miniature castle. Over many hours.
Now I can tinker concept by concept, and build much larger castles, much faster. Like waving a wand, seeing my thoughts come to fruition in near real time.
No vanity lost in my opinion. Possibly more to be gained.
I think there's a disconnect between what you and the person you're replying to are defining as "tinkering". Your conception of it seems more focused on the end product when, to use your analogy, the original comment seems unconcerned with the size of castles.
If you derive enjoyment from actually assembling the castle, you lose out on that by using the wand that makes it happen instantly. Sure wand's castles may be larger, but you don't put a Lego castle together for the finished product.
See that never was the purpose.. going bigger and faster, towards what exactly? Chaos? By the way we never managed to fully tackle manual software development by trained professionals and we now expect Shangri-La by throwing everything and the kitchen sink into giant inscrutable matrices. This time by amateurs as well. I'm sure this will all turn out very well and very, very productive.
I do feel that way, so I'll still do bespoke creation when I want to. But this is like a sewing machine. My job is to design fashion, and a whole line of it. I can do that when a machine is making the stitches instead of my using a needle in hand.
Software engineering requires a fair amount of intelligence, so if these tools ever get to replacement levels of quality then it's not just developers that will be out of jobs. ARC-AGI-2, the countless anecdotes from professionals I've seen across the industry, and personal experience all very clearly point to a significant gap between the tools that exist today and general intelligence. I would recommend keeping an eye on improvements just because of the sheer capital investments going into it, but I won't be losing any sleep waiting for the rapture.
I used to think this way too. Here are a few ways I've tried to re frame things that has helped.
1. When I work on side projects and use AI, sometimes I wonder "what's the point if I am just copy / pasting code? I am not learning anything" but what I have come to realize is building apps with AI assistance is the skill that I am learning, rather than writing code per se as it was a few years ago.
2. I work in high scale distributed computing, so I am still presented with ample opportunities to get very low level, which I love. I am not sure how much I care about writing code per se anymore. Working with AI still is tinkering, it has not changed that much for me. It is quite different, but the underlying fun parts are still present.
We (dare I say we instead of I) like talking to computers and AI is another computer you talk with. So I am still all excited. It's people that I want to avoid :)
At the end of the day, it's your job to deliver value. If a tool allows you to deliver more faster, without sacrificing quality, it's your responsibility to use that tool. You'll just have to make sure you can fully take responsibility for the end deliverables. And these tools are not only useful for writing the final code
It's actually not. My job description does not say "deliver value" and nobody talks about my work like that so I'm not quite sure what to make of that.
> without sacrificing quality
Right..
> it's your responsibility to use that tool
Again, it's actually not. It's my responsibility to do my job, not to make my boss' - or his boss' - car nicer. I know that's what we all know will create "job security" but let's not conflate these things. My job is to do my end of the bargain. My boss' job is paying me for doing that. If he deems it necessary to force me to use AI bullshit, I will of course, but it is definitely not my responsibility to do so autonomously.
> these tools are not only useful for writing the final code
This sparked a thought in how a large part of the job is often the work needed to demonstrate impact. I think this aspect is often overlooked by some of the good engineers not yet taking advantage of the AI tooling. LLM loops may not yet be good enough to produce shippable code by themselves, but they sure are capable to help reduce the overhead of these up and out communicative tasks.
you mean like hacking a first POC with AI to sell a product/feature internally to get buy-in from the rest of the team before actually shipping production version of it?
Congress hasn't actually agreed on a FY2025 budget though right? We're just running on Continuing Resolutions currently. So the budget is actually subject to change when this CR runs out March 14th.
That one always fell flat for me, but I get it. The idea that an emacs user would communicate with another human rather than tinker with their config to deal with the change is unrealistic. /s /sorta
Interesting note about this: the speed of sound on Mars is only ~70% of that on Earth, due to less atmospheric density. Might change your Mach numbers!
The speed of sound in an ideal (calorically perfect) gas is given by
a = sqrt( gamma * R * T )
where gamma is the ratio of specific heats (thermodynamic property of a gas, which may vary with temperature), R is the individual gas constant, and T the temperature of the fluid. All of these are going to be different on Mars versus on Earth:
Earth:
R = R_atm = 287 J / (kg * K)
gamma = 1.44
T = 293 K (taking room temperature as an average temperature)
Mars:
R = R_CO2 = 188 J / (kg * K)
gamma = 1.37
T = 210 K (from a quick google, about -60 deg C)
If the Martian and Earth atmospheres were at the same temperature, then the speed of sound on Mars would be 80% that of the speed of sound on Earth. Given the temperature difference, the speeds of sound are
a_mars = 232 m/s
a_earth = 347 m/s
So yes, much of the difference is due to the composition: the Martian atmosphere has a higher atomic weight, which leads to a lower individual gas constant, and decreases the speed of sound. However, a substantial amount of the difference is simply due to the different temperatures on the surfaces of the two planets.
Final only protects the variable from being assigned a new reference (similar to a const pointer). It doesn’t protect any of the underlying data held by the object from being changed, unless the entire hierarchy has every field declared final as well. I still use final heavily in all of my Java code, but it doesnt convey the full intent I would like it to.
I remember James Gosling saying, a long time ago, that the whole class should be either mutable or not so you do not need to tag some methods with const.
The consequence is that you may define two classes, one non-mutable and one mutable like String/StringBuilder.
It means you have to triplicate each mutable class, because besides the immutable variant you also need the common interface (e.g. CharSequence), in order to pass mutable instances to read-only functions.
Yes, so three classes. I’m counting a Java interface as a class, because it is the same as a purely abstract class. In any case, three different named types.
As a side note, I would say the interface is unmodifiable, not immutable, because references of the interface type may refer to mutable instances that can mutate while you use it through the interface. Immutable = doesn’t change state, unmodifiable = you can’t change it’s state via that reference (but it might change it’s state due to other concurrent code holding a mutable reference). This nomenclature comes from the “unmodifiable” collection wrappers in Java, which don’t make the underlying object immutable.
My philosophy has been to let the distro package manager handle system packages (kernel, OpenSSL, etc) but then use flatpak [1] to install user progs like Chromium and VSCode so I get bleeding edge releases and sandboxing.
I imagine many engineers are like myself in that they got into programming because they liked tinkering and hacking and implementation details, all of which are likely to be abstracted over in this new era of prompting.