91–100 of 384 posts
This essay somehow sounds worse than AI slop, like ChatGPT did a line of coke before writing this out. I use AI everyday for coding. But if someone so obviously puts this little effort into their work that they put out into the world, I don’t think I trust them to do it properly when they’re writing code.
> But guided? The models can write better code than most developers. That’s the part people don’t want to sit with. When guided. Where do you draw the line between just enough guidance vs too much hand holding to an agent? At some point, wouldn't it be better to just do it yourself and be done with the project (while also build your muscle memory, experiences and the mental model for future projects, just like tons o…
I'm not asking an agent to build me a full-stack app. That's where you end up babysitting it like a kindergartener and honestly you'd be faster doing it yourself. The way I use agents is focused, context-driven, one small task at a time.
For example: i need a function that takes a dependency graph, topologically sorts it, and returns the affected nodes when a given node changes. That's well-scoped. The agent writes it, I review it, done.
But say I'm debugging a connection pool leak in Postgres where connections aren't being released back under load because a transaction is left open inside a retry loop. I'm not handing that to an agent. I already know our system. I know which service is misbehaving, I know the ORM layer, I know where the connection lifecycle is managed. The context needed to guide the agent properly would take longer to write than just opening the code and tracing it myself.
That's the line. If the context you'd need to provide is larger than the task itself, just do it. If the task is well-defined and the output is easy to verify, let the agent rip.
The muscle memory point is real though. i still hand-write code when I'm learning something new or exploring a space I don't understand yet. AI is terrible for building intuition in unfamiliar territory because you can't evaluate output you don't understand. But for mundane scaffolding, boilerplate, things that repeat? I don't. llife's too short to hand-write your 50th REST handler.
I agree wholeheartedly with all that is said in this article. When guided , AI amplifies the productivity of experts immensely. There are two problems left, though. One is, laypersons don't understand the difference between "guided" and "vibe coded". This shouldn't matter, but it does, because in most organizations managers are laypersons who don't know anything about coding whatsoever, aren't interested by the topic…
I think the problem is overstated. People always learn the things they need to learn. Were people clutching their pearls about how programmers were going to lack the fundamentals of assembly language after compilers came along? Probably, but it turned out fine. People who need to program in assembly language still do. People who need to touch low-level things probably understand some of it but not as deeply. Most of…
A compiler is deterministic. It's a function; it transforms input into output and validates it in the process. If the input is incorrect it simply throws an error.
AI doesn't validate anything, and transforms a vague input into a vague output, in a non-deterministic way.
A compiler can be declared bug-free, at least in theory.
But it doesn't mean anything to say that the chain 'prompt-LLM-code' is or isn't "correct". It's undecidable.
Lost me at "I’m building something right now. I won’t get into the details. You don’t give away the idea."
Perhaps execution is cheap now and ideas aren't? Personally I'm quite pleased with this inversion.
Eventually you will have to tell people what the idea is, even if it is at product launch. And then, if execution is as cheap and easy as they claim, then anyone can replicate the idea without having to engage with the person in the first place.
Ideas will never not be cheap.
Earlier quoted context omitted.
I am solidly in this "curious" camp. I've read HN for the past 15(?) years. I dropped out of CS and got an art agree instead. My career is elsewhere, but along the way, understanding systems was a hobby. I always kind of wanted to stop everything else and learn "real engineering," but I didn't. Instead, I just read hundreds (thousands?) of arcane articles about enterprise software architecture, programming language d…
You think you know what taste is. Have you been cranking on real systems all these years, or have you been on the sidelines armchairing the theoretics? I'm not trying to come across as rude, but it may be unavoidable to some degree when indirect criticism becomes involved. A laboring engineer has precious little choice in the type of systems available on which to work on. Fundamentally, it's all going to be some vari…
Earlier quoted context omitted.
This is kind of like saying a kid can never become a better programmer than the average of his teachers. IMHO, the reasons not to use AI are social, not logical.
The kid can learn and become better over time, while "AI" can only be retrained using better training data. I'm not against using AI by any means, but I know what to use it for: for stuff where I can only do a worse than half the population because I can't be bothered to learn it properly. I don't want to toot my own horn, but I'd say I'm definitely better at my niche than 50% of the people. There are plenty of other…
By leaving the busywork for the drones, this frees up time for the mind to solve the interesting and unsolved problems.
Earlier quoted context omitted.
The "most engineers" not "most engineers we've hired". But also "most engineers" aren't very good. AIs know tricks that the average "I write code for my dayjob" person doesn't know or frankly won't bother to learn.
Even speaking from a pure statistical perspective, it is quite literally impossible for "AI" that outputs world's-most-average-answer to be better than "most engineers". In fact, it's pretty easy to conclude what percentage of engineers it's better than: all it does is it consumes as much data as possible and returns the statistically most probable answer, therefore it's gonna be better than roughly 50% of engineers.…
That would've taken me 3 months a year ago, just to learn the syntax and evaluate competing options. Now I can get sccache working in a day, find it doesn't scale well, and replace it with recc + buildbarn. And ask the AI questions like whether we should be sharding the CAS storage.
The downside is the AI is always pushing me towards half-assed solutions that didn't solve the problem. Like just setting up distributed caching instead of compilation. It also keeps lying which requires me to redirect & audit its work. But I'm also learning much more than I ever could without AI.
Earlier quoted context omitted.
This is what I find interesting - the response from most companies is "we will need fewer engineers because of AI", not "we can build more things because of AI". What is driving companies to want to get rid of people, rather than do more? Is it just short-term investor-driven thinking?
How much more productive are we supposed to be in engineering? Are we 10x'ing our testing capability at the same time? QA is already a massive bottleneck at my $DAYJOB. I'm not sure what benefits the company at-large derives from having the typing machine type faster.
They will never admit it, but many are scared of losing their jobs. This threat, while not yet realized, is very real from a strictly economic perspective. AI or not, any tool that improves productivity can lead to workforce reduction. Consider this oversimplified example: You own a bakery. You have 10 people making 1,000 loaves of bread per month. Now, you have new semi-automatic ovens that allow you to make the sam…
A bit simplistic. The bakery can just expand its product range or do various other things to add work. In fact that's exactly what I would expect to happen at a tech company, ceteris paribus.
Where is this expanded demand coming from?