161–170 of 263 posts
Earlier quoted context omitted.
How does either of those practices keep code maintainable?
They solve "adding a feature now takes days and breaks two other things".
But if your code is poorly structured, it absolutely does not make it easier to modify.
Creator here, There is a new kind of task for software engineers these days. A client calls, asks for a "small refactor," and sends you 100k lines of AI-generated spaghetti. And this is great! This is something we can work with. Any experienced engineer can look at a codebase like that and quickly see what to refactor, where a library replaces a few thousand hand-rolled lines, and what smells bad. Removing the first…
We replaced a 120,000 USD/year low-code/no-code platform that was running a lot of workflows. And we have another platform that is also similar that we are on track to replace by EOY. Both have been replaced by "vibe" coding. It works well. Everyone's happy. People are having fun with it. We get feature requests, improvements, ideas, feedback. JIRA tickets get created, and we ask AI to reference that ticket, code to…
Earlier quoted context omitted.
Ahh yes the “you’re holding it wrong defense”. Now i ask what enormous extremely complicated projects…excuse me by projects we mean real production software with real scale. Sure, it can poke one system or another but even with opus and now fable, it very quickly hits the limit a limit that tracks very closely with context window. This is to say that no amount of harness tool skill is going to cover that fundamental…
> Ahh yes the “you’re holding it wrong defense” Tools have limitations and ideal uses. If you hammer a nail with a chisel, you're probably going to have a bad time. If you build a home and don't level the joists and studs, you're going to have a bad time. If you use an impact wrench on the wrong part you can cause enormous damage. And so on. Yes, "holding it wrong" is a legitimate thing people can discuss. Similarly…
I think you are projecting other people on to me with is counter productive.
Slop and vibe coding are valid. It is specifically for describing crappy ai output.
You still did not give specifics which is usually the case when pushed on. I will give you some, when there are well over 20 languages that span multiple applications which all can depend on one another in same way, bazel builds from hell. Ya ai cant do it.
Earlier quoted context omitted.
> So what do you / your team do? This is so funny to me, because I know it's asked in earnest but seems so obvious to me: They get actual work done. Programming isn't work. That's just a means to an end. A tool to get the actual job done. At least in most orgs. Obviously there are exceptions - but the vast economy is not a bunch of software companies. It's companies doing things to build a physical product, and softw…
It's interesting how people view software as a distraction and an annoying side quest/cost center, but never apply that to, say, 90% of what management does. None of that "directly" makes money either! That tells us a lot more about the leadership and management philosophies at modern companies than anything fundamental about what kind of work actually matters.
Perversely I find myself increasingly blaming the growth of product management divorced from engineering as the source of some of this.
Everyone wants to be the next Jobs, but somehow they missed that it was the marriage of high quality design and high quality engineering that got Apple where they are today.
Rather, the lesson they learned is that PMF and UX and yadda yadda yadda are all that matter and coding is just a means to an end.
It'll be interesting to see how many companies discover that you can't achieve those ends if you build on a broken foundation.
“We use Claude Code too” I understand that it’s probably impossible to sell non-AI-assisted solutions to AI-pilled companies (even when their headaches are AI-induced), but my gut reaction to “take an AI-inflated codebase and apply AI deflation to it” is something like “that’s akin to applying two rounds of lossy transcoding; the errors don’t cancel out, they cross-multiply”.
The level of "slop" produced by AI is a direct function of skill of the developer and broadness of the prompts. Broad prompts by unskilled users results in a complete mess. Targeted prompts by a skilled person reviewing the code produces something better. Quality of application varies widely, and generally agree with the categories mentioned by the sibling post.
Process was - produced a detailed feature spec - multiple iteration of "I want this and that", make it into coherent spec", "this this and that is not correct, change to that". Made it write architecture spec(which I didn't read because too unfamiliar) and split it into tasks. Then it was implementing tasks, after each I did a change/fix those ~10 things iteration and spec corrections.
It was good to a point, but then when I started to hit performance problems I had to step in look at the code, and very often fight with CC, confront its "this is the only way", force it to do web search for proper ways to deal with problems and even explain very simple things about proper DB usage.
At some point it asked me something like "is it ok for schema migration to just fail or we need to implement complicated handling?", I have answered "it just shouldn't leave app locked in schema failure", and guess what was CC solution? - it wrote an error handler which just drops DB and recreates fresh one on ANY schema failure. And if I didn't happen to peek at the code and ask wtf it is doing, that would've been an exiting UX.
I've spent about month's worth of $20 CC subscription tokens using Opus 4.8 on xhigh, AND about 70 hours of my time to get it to a point where it is good.
So "anyone can just code what they want now" is correct only to a point, MVP will work, but beyond that experience will be subpar, and it still needs lots and lots of iterations of explaining what you want. Then because normal user knows very little about how software works they won't be able to ask AI the right questions, confront it and rate of improvement vs token usage will hit rock bottom.
Earlier quoted context omitted.
> It's de-personalized I had an interesting conversation with a junior engineer who made this observation. She shipped a feature, we gathered data, and based on data we pivoted to a different design. She called out that she wasn’t attached to the code because AI wrote it. Not that she didn’t care about quality or effectiveness of the product, but the personal emotional attachment to the code itself was not there. Pro…
So then, why have the junior engineer in the first place?
Earlier quoted context omitted.
Same here. Honestly, there's also a bunch of human friction that goes away. I can tell a junior that a change needs to be significantly refactored (or even thrown away entirely) without the psychological damage of discarding days/weeks of work from them. Previously, I would need to do the trade-off calculation. How urgently does this need to ship, and do we have time to rework this? What are the deal breakers that ne…
> It's de-personalized I had an interesting conversation with a junior engineer who made this observation. She shipped a feature, we gathered data, and based on data we pivoted to a different design. She called out that she wasn’t attached to the code because AI wrote it. Not that she didn’t care about quality or effectiveness of the product, but the personal emotional attachment to the code itself was not there. Pro…
This line made me chuckle. I see what you did there: > No cookies. No tracking. No JavaScript. Real people.
We replaced a 120,000 USD/year low-code/no-code platform that was running a lot of workflows. And we have another platform that is also similar that we are on track to replace by EOY. Both have been replaced by "vibe" coding. It works well. Everyone's happy. People are having fun with it. We get feature requests, improvements, ideas, feedback. JIRA tickets get created, and we ask AI to reference that ticket, code to…
This industry's complete outsourcing of its core business value on a third party proprietary subscription based tool, Claude, made by an unprofitable company, Anthropic, is very concerning. You are all lunatics, sorry.