Comment by ramathornn
17 hours ago
> BTW, I think a lot of people were/are greatly overestimating the value of coding to business success.
Fully agree - We already saw dev prices drop significantly when offshore dev shops spun up. I've had great, and also horrible experiences working with devs that could produce lines of code at a fraction of the price of any senior type dev.
The higher paid engineers i've worked with are always worth their salary/hourly rate because of the way they approach problems and the solutions they come up with.
Agents are great at building out features, i'm not so sure about complex software that grows over time. Unless you know the right questions to ask, the agent misses alot. 80/20 doesn't work for systems that need 100% reliability.
I think it's really dependent on the software. And frankly, with the current rate of development, I feel like this continues to shift.
No, a non-engineer can't just spin up the next great app. Even with the newest models and a great prompting/testing system, I don't think you can just spit out high quality, maintainable, reliable code. But as a generalist - I'm absolutely able to ship software and tools that solve our business problems.
Right now, my company identified an expensive software platform that was set to cost us around $250k/year. People in the industry are raving about it.
I've spent 1-2 weeks recreating the core functionality (with a significantly enhanced integration into our CRM and internal analytics) in both a web app and mobile application. And it's gone far smoother than I expected. It's not done - and maybe we'll run into some blocker. But this would have taken me 6 months, at least, to build half as well.
I was an AI skeptic for most of last year. It provided value, sure, but it felt like we were plateauing. Slowing down.
I'd hoped we might be slowing down to some sort of invisible ceiling. I was faster than ever - but it very much required a level of experience that felt reasonable and fair.
It feels different now.
I'd say ~70% of my Claude Opus results just work. I tweak the UI and refactor when possible. And it runs into issues I have to solve occasionally. But otherwise? If I'm specific, if I have it brainstorm, then plan, and then implement - then it usually just works.
> Right now, my company identified an expensive software platform that was set to cost us around $250k/year.
A single engineer assigned to maintain your in-house solution will cost more than this.
A single engineer in urban America.
> No, a non-engineer can't just spin up the next great app. Even with the newest models and a great prompting/testing system, I don't think you can just spit out high quality, maintainable, reliable code
I think most engineers vastly overestimate how important high quality, maintainable, reliable code is to product success. Yes, you need an experienced engineer to steer Claude into making good high-quality code. But your customer doesn't see your code, they don't see how many servers you need or how often an on-call engineer is woken up. They just see how well the app meets their needs
I predict we will see a lot of domain experts without engineering background spin up incredibly successful apps. Just like the Tea app many of them will crash and burn from poor engineering. But there will also be enough people who've grown wise to this and after reaching some success with their app spend the resources to have others mitigate all the unknown-to-them issues
> I think most engineers vastly overestimate how important high quality, maintainable, reliable code is to product success.
I agree, the only thing I can’t get past is the black box approach. For the majority of business stakeholders, they can’t/ don’t want to read the code that Opus, or any other agent produces. It will most likely work, but if it doesn’t, they have to rely on the agent to find & patch.
I’m with you though, it’s getting incredibly good at doing that, but that concept of “It works but I don’t know why” seems very dangerous at scale.
That last mile for apps isn’t trivial imo; to take them from “it’s cool and does exactly what I want”, to a scenario where all employees at our company can use it.
But who knows I might just be a naive dev lol, this stuff is changing too quickly.
> I think most engineers vastly overestimate how important high quality, maintainable, reliable code is to product success.
Rather: Many software developers overestimate how important high quality, maintainable, reliable code is to initial product success.
Once the product is highly successful, a high quality, maintainable, reliable code pays huge dividends - and I have a strong feeling that most business people vastly underestimate this dividend.
> I predict we will see a lot of domain experts without engineering background spin up incredibly successful apps. Just like the Tea app many of them will crash and burn from poor engineering.
This rollercoaster is going to be wild to ride over the next decade. I've done a few experiments where I've intentionally "vibe coded" either a few features for an existing project of mine or for a few completely clean-sheet ideas.
I completely agree with you. There are going to be a lot of domain experts who do successfully spin stuff up.
> But there will also be enough people who've grown wise to this and after reaching some success with their app spend the resources to have others mitigate all the unknown-to-them issues
Here's the part that shocked me when I tried this... it did not take long for the no-engineering-guidance codebases to turn into complete disasters. Like... in an afternoon I had a pretty functional application that filled a gap for me. It was also... I don't think it'd remain even remotely maintainable for more than a week based on the direction it was going.
We live in interesting times.
> I think most engineers vastly overestimate how important high quality, maintainable, reliable code is to product success. Yes, you need an experienced engineer to steer Claude into making good high-quality code. But your customer doesn't see your code, they don't see how many servers you need or how often an on-call engineer is woken up. They just see how well the app meets their needs
Your customers definitely see the quality of code, just by proxy. When features take forever to ship, and things fall over all the time, those are code quality and design problems.
Honestly, code quality is somewhat more important right now, because use common and clear patterns will help AI make better changes, and using a more resilient architecture will you hand more off without worry things will fall over.
> The higher paid engineers i've worked with are always worth their salary/hourly rate because of the way they approach problems and the solutions they come up with.
I'm honestly just happy at the moment, because our two junior admins/platform engineers have made some really good points to me in preparation for their annual reviews.
One now completed his own bigger terraform project, with the great praise of "That looks super easy to maintain and use" from the other more experienced engineers. He figured: "It's weird, you actually end up thinking and poking at a problem for a week or two, and then it actually folds into a very small amount of code. And sure, Copilot helped a bit with some boilerplate, but that was only after figuring out how to structure and hold it".
The other is working on getting a grip on running the big temperamental beast called PostgreSQL. She was recently a bit frustrated. "How can it be so hard to configure a simple number! It's so easy to set it in ansible and roll it out, but to find the right value, you gotta search the entire universe from top to bottom and then the answer is <maybe>. AAaah I gotta yell at a team". She's on a good way to become a great DBA.
> Agents are great at building out features, i'm not so sure about complex software that grows over time. Unless you know the right questions to ask, the agent misses alot. 80/20 doesn't work for systems that need 100% reliability.
Or if it's very structured and testable. For example, we're seeing great value in rebuilding a Grafana instance from manually managed to scripted dashboards. After a bit of scaffolding, some style instructions and a few example systems, you can just chuck it a description and a few queries, it just goes to successful work and just needs a little tweaking afterwards.
Similar, we're now converting a few remnants of our old config management to the new one using AI agents. Setup a good test suite first, then throw old code and examples of how the new config management does it into the context and modern models do that well. At that point, just rebuilding the system once is better than year-long deprecation plans with undecided stakeholders as mobile as a pet ferret that doesn't want to.
It's really not the code holding the platform together, it's the team and the experiences and behaviors of people.
It makes sense for junior admins and junior platform engineers to leverage LLM's but I'd be highly skeptical for the future skillset of any junior software engineer who leverages LLM's right off the bat, unless we have already moved that goalpost.
Depends how they use them as arguably was the case with stack overflow or other resources in the past. E.g. an LLM can be a valid and useful way to start discovering or understanding code and architecture. You can ask for a summary , distill important concepts and then read in more detail about them.
Ya, this is the issue. LLMs are not great for developing minds. A lot like the internet presently, to be frank.
For fully developed and experienced minds, both can be useful.
2 replies →
> He figured: "It's weird, you actually end up thinking and poking at a problem for a week or two, and then it actually folds into a very small amount of code. And sure, Copilot helped a bit with some boilerplate, but that was only after figuring out how to structure and hold it".
Let me just get you that Fred Brooks quote, now where was it...? Ah, yes, here's one:
https://news.ycombinator.com/item?id=4560756
We didn't even have to offshore for lots of bad code to be written.
Looks at the scores of Ycombinator startups that wrote a shitload of awful code and failed. Good ideas, pretty websites, but not a lot of substance under the hood. The VC gathering aspect and online kudos was way more important to them than actually producing good code and a reliable product that would stand the test of time.
Pretty much the most detestable section of the HN community. IMNHSO. I notice they're much quieter than usual since the whole vibe coding thing kicked off.
> Looks at the scores of Ycombinator startups that wrote a shitload of awful code and failed.
This can also be restated as, look at all the startups that wrote a shitload of awful code and succeeded.
That’s an indicator code quality doesn’t matter at macro scales. We already knew this though even if we didn’t explicitly say it. It’s more about organization, coordination, and execution than code.
This seems like it's reading too much into things. I'm sure driving an ambulance slower vs faster doesn't make a difference to survival in most cases, but on the margins it absolutely does.
Startups are also quite different from ambulances; surviving and minimising patient harm isn't the most important thing for a startup. Instead, it's building a profitable and valuable business. You're not just worrying about the margins, you're also hoping to squeeze out every bit of growth you can.
> That’s an indicator code quality doesn’t matter at macro scales.
I think it can though. It just depends. Having high quality code and making good technical choices can matter in many ways. From improving performance (massively) and correctness, to attracting great talent. Jane Street and WhatsApp come to mind, maybe Discord too. Just like great design will attract great designers.
I also think it might matter even more in the age of AI Agents. Most of my time now is spent reviewing code instead of writing code, and that makes me a huge bottleneck. So the best way to optimize is to make the code more readable and having good automated checks to reduce the amount of work I need to do, like static types, no nulls, compilation, automated tests, secondary agent reviews, etc.
I mean, look at all the startups that succeeded despite being complete shitshows behind the scenes... the baseline for leadership, organization, coordination or, hell, execution for a startup to succeed isn't exactly high either.
They left ages ago, around the time PH got big.
I can't remember the last time I saw a '10 ways to fit 25 hours in 24 hours' type article on here, which were rife 10 years ago.
What's PH?
1 reply →
I think it is a misnomer to attribute startup failure to bad code. There are so many other factors at play that are more powerful.
Not to say the crowd u speak of doesn’t exist, they do.
Bad code is one possible axis - not a likely one at that stage though. Bad code gets you a few years down the line when competitors are moving faster than you to the point where they are cheaper and better.
One thought experiment I keep having when I see LLM hype: imagine if our outsourcing companies could be as blasé about copyright as OpenAI, and how profitable they could be.
I mean, rename some dudes over there to ‘transformer’, and let them copy & paste from GitHub with abandon… I know we could get a whole browser for less than a few grand.
We wouldn’t, because it’d be copyright-insane. But if we just got it indirect enough, maybe fed the info to the copiers through a ‘transforming’ browser to mirror the copyright argument, I bet we could outperform OpenAI in key metrics.
Coding is formalizing for the compiler. The other 99% of the job is softly getting the PHB not to fuck the entire company and being unique in not doing dumb shit everyone thinks is popular now but will regret soon. It’s all like IT tribal tattoos. Barely cool for a couple of years, and then a lifelong source of shielded regret.
I'm surprised you think this hasn't been happening for years, in smaller offshore shops.
PHB = pointy-haired boss?
Here's the thing though, and with all due respect I say this as someone who has worked with offshore teams.
They were only as good as the input they were given. They rarely went above and beyond, and most of the time getting something "good enough" was challenging. Yes, time zones, cultural differences/attitudes, and their exposure/opportunities play a big role.
What I'm saying is that teams who had bad onshore employees got horrible results. Teams that had actual systems engineers and people who could architect systems usually got great results.
For example, we were building a bleeding edge (at the time) e commerce site for one of the largest companies in the entertainment space. I made sure to work with the best people I knew at the company to design the system from the ground up. Then, we made sure the actual "functional" pieces were digestible and written plainly that we didn't need to clarify words. Nor did we write a fucking 300 page technical document. We kept things simple and effective, and all the work was broken down into as atomic pieces as possible.
The end result was that we used a team distributed between Ukraine and India to build this in about 4 months. We'd do weekly sprints, and the team had great spirits too because we actually gave a fuck about them and ensuring their success. I'm sure they're used to being scapegoats because of some lazy fucks onshore.
Now I use agents daily and have great success. However, the whole "write a sentence and AI will do it for you" is obviously bullshit. I even asked HN why I got wrong results to test what people would respond (sorry for playing you) and as I predicted they blamed me thus proving that this broader sentiment that's so prominent by "thought leaders" is stupid as fuck. So, that's where we are.
People who can actually build great systems know that it requires careful planning, deep understanding, and ability to fill in the gaps.