I wonder at the end of this if it's the still worth the risk? A lot of how I form my thoughts is driven by writing code, and seeing it on screen, running into its limitations. Maybe it's the kind of work I'm doing, or maybe I just suck, but the code to me is a forcing mechanism into ironing out the details, and I don't get that when I'm writing a specification.
Some people like to lay the brick, some people like to draw the blueprints. I don’t think there is anything wrong with not subscribing to this onslaught on AI tooling, doing the hard work is rewarding. Whether AI will become a standard in how code is written in the future is still to be determined and I think there is a real chance that is where it goes, it shouldn’t hinder your love for doing what you do.
I wonder at the end of this if it's the still worth the risk? A lot of how I form my thoughts is driven by writing code, and seeing it on screen, running into its limitations. Maybe it's the kind of work I'm doing, or maybe I just suck, but the code to me is a forcing mechanism into ironing out the details, and I don't get that when I'm writing a specification.
Some people like to lay the brick, some people like to draw the blueprints. I don’t think there is anything wrong with not subscribing to this onslaught on AI tooling, doing the hard work is rewarding. Whether AI will become a standard in how code is written in the future is still to be determined and I think there is a real chance that is where it goes, it shouldn’t hinder your love for doing what you do.
100%. To me the real question is whether all the bother getting the agents to not waste time nets out to real gains, or perceived gains (while possibly even losing efficiency).
It's not at all clear to me which is true given the level of hype and antipathy out there. I'm just going to watch and wait, and experiment cautiously, till it's more clearcut.
The post touches very briefly on linting in 7. For me, setting up a large number of static code analysis checks has had the highest impact on code quality. My hierarchy of static analysis looks like this (hierarchy below is Typescript focused but in principle translatable to other languages): 1. Typesafe compiler (tsc) 2. Basic lint rules (eslint) 3. Cyclomatic complexity rules (eslint, sonarjs) 4. Max line length en…
Very nice. BUT, what is the point of max line length enforcement, just to see if there are crazy ternary operators going on?
No, I mean that my job in its current form – as an ML researcher with a phd and 15 years of experience - will be completely automated within two years.
What are you going to do for work in 2 years?
I have enough savings for a few years, so I might just move to a lower COL area, and wait it out. Hopefully after the initial chaos period things will improve.
That sounds like the advice of someone who doesn't actually write high-quality code. Perhaps a better title would be "how to get something better than pure slop when letting a chatbot code for you" - and then it's not bad advice I suppose. I would still avoid such code if I can help it at all.
Look up luddites on Wikipedia, might be too deep to see the similarities though.
> workers who opposed the use of certain types of automated machinery due to concerns relating to worker pay and output quality... Luddites were not opposed to the use of machines per se (many were skilled operators in the textile industry); they attacked manufacturers who were trying to circumvent standard labor practices of the time.
No, I mean that my job in its current form – as an ML researcher with a phd and 15 years of experience - will be completely automated within two years.
Is the progress of LLMs moving up abstraction layers inevitable as they gather more data from each layer? First, we fed LLMs raw text and code and now they are gathering our interactions with the LLM regarding generated code. It seems like you could then use the interactions to make a LLM that is good at prompting and fixing another LLMs generated code. Then its on to the next abstraction layer.
What you described makes sense, and it's just one of the things to try. There are lots of other research directions: online learning, more efficient learning, better loss/reward functions, better world models from training on Youtube/VR simulations/robots acting in real world, better imitation learning, curriculum learning, etc. There will undoubtedly be architectural improvements, hardware improvements, longer context windows, insights from neuroscience, etc. There is still so much to research. And there are more AI researchers now than ever. Plus current AI models already make us (AI researchers) so much more productive. But even if absolutely no further progress is made in AI research, and foundational model development stops today, there's so much improvement to be made in the tooling around the models: agentic frameworks, external memory management, better online search, better user interactions, etc. The whole LLM field is barely 5 years old.
there are some youtube videos about the topic, be it pupil in high school addicted to llms, or adults losing skills, and not dev only, society is starting to see strange effects
Can you provide links to these videos?
This one is in french (hope you don't mind), https://youtu.be/4xq6bVbS-Pw?t=534 mentions the issues for students and other cognitive issues.
I'd add: Religiously, routinely refactor. After almost every feature I do a feature level code analysis and refactoring, and every few features - codebase wide code analysis and refactoring. I am quite happy with the resulting code - much less shameful than most things I've created in 40 years of being passionate about coding.
This. Historically there's been a lot of resistance to the idea of refactoring or refining features. The classic "It works, just ship it" mentality that leaves mountains of tech debt in its wake. And there _was_ a good reason to resist refactoring. It takes time and effort! After "finishing" something, the timeline, the mental and physical energy, the institutional support, is all dried up. Just ship it and move on.…
We are becoming spec writers, wearing the PM/lead hats.
1) Do a gap and needs assessment.
2) Build business requirements.
3) Define scope of work to advance fulfillment.
4) Create functional and non-functional specs.
5) Divide-conquer-refine loop.
I wonder at the end of this if it's the still worth the risk? A lot of how I form my thoughts is driven by writing code, and seeing it on screen, running into its limitations. Maybe it's the kind of work I'm doing, or maybe I just suck, but the code to me is a forcing mechanism into ironing out the details, and I don't get that when I'm writing a specification.
Some people like to lay the brick, some people like to draw the blueprints. I don’t think there is anything wrong with not subscribing to this onslaught on AI tooling, doing the hard work is rewarding. Whether AI will become a standard in how code is written in the future is still to be determined and I think there is a real chance that is where it goes, it shouldn’t hinder your love for doing what you do.
Same reason people build their own homes by hand, for the challenge because YOLO.
Spec-driven development is the only reliable way to work with AI. That's my current understanding. I spend more time refining the spec and bouncing ideas off of AI/team than before, which is good before there can't be any incorrect assumptions or hidden variables, otherwise AI will create suboptimal code. We should have been doing this much earlier in the process, even without AI, but now it's more necessary than ever. If you keep asking AI to make small changes as you learn about the business domain of your project, it will create a mess, in my experience. It's better to start from scratch and ask it to reimplement, if you finally understand all the requirements.