Posted by dimonomid 14 hours ago
1) A lot of the time i spent deciding on interfaces (methods, classes, etc.) for humans. E.g. should this be two methods or one, should this method be in this class or moved to utility. Those problems went away. 2) What about performant code? This can be prompted away and when the measurements in your performance tests do not go down, then you can step in. 3) Sad to say but the AI has always been better than me at code-reviews. Maybe this is just me and if so I own that, but to the articles point, it might be harder to fix now. 4) "vibe-coded projects devolve over time into an unmaintainable mess". Preventing and managing this mess is the new skill sets we need to develop as software engineers. 5) Another skill-set we will need to master is how to maintain and grow our coding skills. Some ideas are: a) every once in a while implement a feature yourself. b) no AI Tuesdays! c) Have the AI quiz you on the code base. d) Have the AI develop HTML docs about how the code works.
One set goes into haxe files and I use reflaxe macros to write tiny compilers that generate docs, clients, servers, cli's, test cases, serializers and deserializers, etc in whatever language is appropriate. That leaves gaps, which the AI can then fill in.
So I iterate on the haxe stuff. If the AI is struggling to "draw the rest of the owl," I change the source of truth until it has enough guidance re: type related errors, failing tests, and documentation. As requirements change, these things change.
As for the rest of the owl, it's disposable. Every few months I'll delete it and have an AI rewrite it from scratch (now with a smarter model and better docs and API specs and tests to guide it). This keeps the cruft from accumulating while preserving human contact with the code.
How can we prevent and manage the mess if we're not actively working in the codebase though? (Sometimes, I'll get a 'feel' for when something needs changed or will become unmaintainable, but that required consistently interacting with the thing)
Currently, we look at code once during the PR and then we never touch it again until it comes up in the PR.
I'm still handling a few tickets a week without AI, because sometimes it's faster to make a 2 line fix than to write + review a prompt, but increasingly it's just to make sure I still 'got it'.
2) not even sure what you mean by this
3) probably shouldn't admit that. It implies the reviewer has a less than average understanding of the code they're reviewing.
4) preventing and managing vibe code devolving into a pile of slop requires programmers not use AI. 80% accuracy repeated in more and more layers === more and more failures. In other words, the skill required is exactly the skill of being a good programmer without AI.
5) e) no AI all the time or only use AI as search. You're almost there with a and b. With c, it just doesn't understand well enough to "quiz you". With d, how are you going to know if the docs are correct if you aren't reading the slop?
This takes time away from implementing new features, but that’s true of all code health maintenance.
This only works in small projects. For large projects, it is close to impossible. Everybody talks about how new models appear all the time and nobody comments on the fact that context size has almost stalled.
You can split a small program into piece A, B, C All of them look correct on their own. But they duplicate something in 3 different ways and person/agent who can "see" all of them can see the duplication and refactor.
Current model context is simply not enough for large projects.
Same problem for letting AI review code. A PR might look correct on its own and be small enough to fit into context. But somebody who has access to the whole code of the project again sees the duplication.
I am an OSS developer and when reviewing PRs I actually look at how the same problem was solved in other popular OSS projects. No AI can check this today because there is simply not enough context.
Basically if we had unlimited context what you said might be true. But context size is limited today.
Yes a plugin system is great, but it only works if that plugin API/interface it designed correctly and gives plugins what they need while still enforcing good practices.
But somebody needs to design a plugin system that does this first. And designing a plugin system (for large projects) brings us back to square 1 :-) (that you need a large enough context to see what the code does in order to anticipate plugin needs).
Putting in massive effort with AI leads to quality exactly like before hand coding.
Vast majority of work was junk before AI because vast majority of people put the minimal possible effort.
The difference now is that AI can make low effort work look high effort at a surface level.
True, but we'll also get higher standards I think. It's become easier to do things, so skilled people can do more complicated things. We compare to what humans can achieve.
I'm weirdly attached to this line. Physical automation a.k.a. factories are not portable. The manufacturing techniques are, but to "spin up" a new factory requires expertise, effort and capital. In contrast to software, replication can be done quite effortlessly, with containers and such tools, it's easily a one-man job.
Writing, coding and art are not meant to be repetitive, scalable tasks. I think that's what's driving the core of the backlash. If these forms of human expressions can be automated, then why would we need to apply our mental capacity at all?
What worries me more is my own tendency to rely on AI more and more. It is becoming increasingly difficult to choose the harder path of coding by myself instead of taking the easier road, even though I know that road may gradually make me lose some of my skills.
Fortunately, I am closer to the end of my career than the beginning, but I worry a great deal about the new generation of developers.
So now we have a fork: red-pillers who want to regenerate software all the time (esp those with unlimited token budgets) and blue-pillers who want to maintain more code mass per developer-head. Plus, we have software artisans.
That will be an interesting horse race.
Too often people get an idea and don't stop to ask if there is an even better idea. (I'm guilty of this myself). Often it takes a while to figure out what the good ideas are, but people want an answer now.
>In the future we will see more and more companies proudly boasting their “NO-AI” policy as a competitive advantage. And they will be right.
I will very happily take the other side of this bet. Maybe if LLMs stayed as September 2026 LLMs for the next 20 years, I'd grant it's possible. But that's not what's going to happen.
I guess there's no reason to believe these models can't be as smart as a great software architect / engineer or team of such people that build an elegant and maintainable software solution over many years together based on customer feedback, then again the models are appallingly bad at some forms of reasoning, I mean they will "understand" something once you make them aware of it like e.g. a flaw in the software architecture, but when asking them to audit the code and check for issues they will often have a blind spot to finding such problems. It's interesting, like they have very high ability but very little awareness or self-directed thinking outside of the prompts they receive.
I experience all the same issues you mention. I am just predicting where the ball is moving. In the scheme of things, LLMs have been useful for coding for, what, like... 1.5 years??? What other technology has ever existed where people expect it to go from "just came out" to "changes everything for everyone" in 2 years?
In the arc of history I see us at the very, very early stages of AI-driven software development.