When chess engines surpassed human grandmasters, something unexpected happened: for a period of time, the strongest players weren’t humans or machines, but combinations of both — “centaurs.”
The engine handled calculation. The human decided which lines were worth calculating.
As engines improved, they absorbed that layer too, and the human role moved up the stack.
I think something similar is happening in engineering.
AI tools are making it much cheaper to produce code, documentation, and designs. As a result, output quality is becoming a weaker signal of experience than it used to be — not because expertise matters less, but because it shows up differently.
The constraint is shifting toward deciding which problems are worth solving, spotting flaws before implementation, and asking the right questions early.
When producing outputs becomes cheap, the value moves toward deciding what should be produced.
This doesn’t mean junior and senior engineers are equivalent — system-level thinking still separates them. But the surface signals organizations use to detect that difference are compressing quickly.
Curious if others are seeing this in how they hire and evaluate engineers.
while true javascripts missing a "real" standard library - I don't see how, even if one was created, it would be able to keep up with the pace of the community...
If your referring to external dependancies as "how many times you require a dependency in your code", then realize that large projects like babel are actually composed of smaller dependencies under the covers: https://github.com/babel/babel/tree/master/packages
So wrapping smaller packages in a larger package doesn't change whats happening behind the scenes.
If your referring to "just not having external dependancies at all" then good luck writing anything of value without first recreating the wheel.
As to the question of if the code is modified, thats what semver is for. Production apps should always link to a specific version of a library.
I had similar thoughts when creating this, but in the end I felt like it would promote using GitHub as a place where you keep your toolboox / have fun - and less a place where recruiters will blindly look at your "streak" count to decide whether you are a good developer or not.
For small programs you will be able to remove the ZALGO-like text. Since it replaces the actual variable names with an obfuscated name, you wont ever be able to get the original code back (i.e. 'var foo' will become 'var he_comes123'. With a lot more code will make the reverse-engineering not worth the time spent recreating the original.
See the look_of_disapproval option of gulp-obfuscate for another example:
function ಠ_ಠ4() {
var ಠ_ಠ1, ಠ_ಠ2, ಠ_ಠ3;
...
ಠ_ಠ3 = ಠ_ಠ1 + ಠ_ಠ2;
return ಠ_ಠ3;
}
Good point. Hmm, so I am seeing great benefits in using HTML5 canvas for the UI, and I believe as people start expecting more and more from their web experience we will see more UIs moving to canvas. Are you aware of any efforts out there to merge HTML5 interfaces with some of the standards we have with traditional HTML interfaces?
I wanted to show HN my latest work, www.graffitidrop.com, and get some feedback from the community. 99% of the interaction on the site is through HTML5 canvas. I found that HTML5 canvas allowed for a more fluid interface, so I thought I'd pose the question "are HTML5 canvas based UI's the way of the future?".
Thanks for the feedback! The UI was something very important to us. There are still a few things that can be "tweaked" to make things more efficient, but figured it was good enough to start getting user feedback. Thanks again.
The engine handled calculation. The human decided which lines were worth calculating.
As engines improved, they absorbed that layer too, and the human role moved up the stack.
I think something similar is happening in engineering.
AI tools are making it much cheaper to produce code, documentation, and designs. As a result, output quality is becoming a weaker signal of experience than it used to be — not because expertise matters less, but because it shows up differently.
The constraint is shifting toward deciding which problems are worth solving, spotting flaws before implementation, and asking the right questions early.
When producing outputs becomes cheap, the value moves toward deciding what should be produced.
This doesn’t mean junior and senior engineers are equivalent — system-level thinking still separates them. But the surface signals organizations use to detect that difference are compressing quickly.
Curious if others are seeing this in how they hire and evaluate engineers.