These posts where people start from a worldview that believes AI can and will do everything all have a flawed premise. It can't. It won't.
Even if it could, it is a bad idea. How many sob stories are posted to HN about someone building a small startup that is utterly reliant on a 3rd party, and then they crash out and fail when that 3rd party has a problem. And the responses are always the same: "ooh, harsh way to learn that lesson... sorry." AI is no different. It is a 3rd party dependency. It will fail you. You need to have the skills to respond and adapt when those failures occur.
If AI helps you and makes your life easier, great. Use it. If it does 98% of the work for you, that is amazing. But if you could not have done it without AI, then it isn't helping you, it is a crutch. Think about airline pilots. They often (mostly?) just chill and observe while the autopilot does everything. But they can step up, take control, and do everything when needed. Can you imagine flying with a pilot who says, "No, I don't know how to land a plane. The autopilot does that for me." Don't be the software equivalent of a pilot who can't land their own plane.
It isn't 10% less quality. It is more like 90% less quality. It does great at basic coding, but still royally sucks at system design. It codes itself into corners that need to be completely refactored. It picks the first path it sees that works, even if there are better solutions, because it doesn't understand what is available as built-in features of different tech stacks and platform. Or, to be more accurate, it doesn't understanding a single thing it is saying, so has zero thought to put into what is actually the correct solution. My favorite one is when it delivered a DB schema to me that re-invented auto-incrementing fields by creating new stored procedures and triggers... for IDs that weren't even auto-incremented.
So I feel just fine. I use AI when it helps, I do the work myself when it doesn't. All you need to do is learn which is which.
Depends on who is doing the work. If you are a junior who doesn't have any fundamentals and/or started career after 2022+, I wouldn't trust the AI code. However, if you were already a senior/experienced architect, AI is superpower.
Which tool are you using and whats your tech-stack? my experience is not same as your in terms of quality, our stack is primarily Java
> It codes itself into corners that need to be completely refactored
This part is important, if you give full autonomy indeed code becomes mess, but then there are 2 aspects to it: (1) so what? it becomes mess, anyway is code read by agents and written by agents these days (not fully, but a lot). (2) eventually things get complex very quickly, that you wont be able to build mental models about the project, because it wasnt written by you, which forces you to use agents even more, leading to almost complete autonomy, at some point, you wouldn't understand the code anyways.
Truly a good idea, but it is somewhat hard to evaluate this when all we get are a couple high level graphs, and everything else is marked as "Unlock with Pro"
The freemium model is in and of itself interesting because most tech leaders in the public sector are quite allergic to the idea of monetizing the public view of data and content. They want the organizations who produce the data to fund the platforms, with the public views being a key piece of the puzzle, but not the funding source. I'm actually with you on it, that if the public wants deep engagement, it is worth some small fees. But we're the minority - most folks with whom I've discussed projects vehemently reject the idea.
As you are also asking for a "Pro" subscription for API access, I'd open up the public view and rely instead on API fees.
I hear ya. I'm just unsure that people will even use the API enough. That is assuming that most of the people that would use this/hangout here are programmer-y.
Perhaps I can make more things seen in the "Free tier"
> We can only speculate... Here are a few possibilities...
AI-generated or not, this is the tech blog equivalent of fan fiction, just making guesses based on a one-liner where Anthropic said they have 1000 customers at $1M+ ARR.
School walkouts typically have nothing to do with the school itself, and certainly do not ask for it to be allowed. It is the kids who walk out. The schools typically treat it like any other unexcused absence.
OK, cool, but... why? If your goal is release notes with content meaningful to the user, not just tech details, wouldn't it be even easier/better/cheaper to just send the content of Jira tickets instead of all the code into your context? (Or whatever PM system you use to track your product work)
After all, that would include user-meaningful content already as well as priorities and other business context. Why guess information from code when there is probably already a system that has those answers?
Edit: I just saw where you posted this a month ago, too. From that post: "I'm a PM at Arthur. Every release I'd spend hours combing through commit logs and PRs trying to write something coherent for our users. "
Now I'm doubly confused. You are a PM who doesn't track the work? You comb through code? This makes so little sense. That isn't at all typical of how PMs work?
No, I have the opposite reaction. A new company with funding to me just implies a runway that will run out, and no profitable business attached to it. Show me a balance sheet that is self-sustaining on their own revenue, and I'll work with them over VC-funded startups any day.
Are you joking? The cost of writing code is practically free. Some basic hosting is very cheap. Find just a couple of paying customers and you are self-sustaining. Hire only when the revenue supports it, and you remain that way.
I think it is a lower level problem than that. "Founders" fall into the trap of thinking that getting funding is a fundamental aspect of building something new, when it is not. Instead of building a solid business plan, then applying funding if and where needed to resolve constraints of carrying out the plan, they make their plans with funding as the primary goal, and only later determine whether or not it is actually a viable business.
This is exactly right and there's a tell that I've noticed after reviewing hundreds of decks and talking to a lot of founders.
You can figure out pretty quickly whether a founder has been forced to actually sell something or whether they've been living in pitch mode. And the difference shows up in a really specific way.
Ask them about their customers. The founders who had to sell to survive talk about specific people. They know the person's name, what their actual objection was, why the third conversation went differently than the first two, what made them finally sign. The detail is almost uncomfortable sometimes.
The pitch mode founders talk about personas. "Our customer is a mid-market ops manager who struggles with workflow inefficiency." Technically an answer. Completely useless information that tells you they've been reading about their customer rather than talking to them.
The brutal thing is that early fundraising success can actually mask this for a long time. A founder who raises a seed round before they've had to sell anything gets 18 months of runway to stay in pitch mode. They raise the seed talking about potential. They raise the A talking about momentum. By the time you're at the B someone finally asks a hard question and there's nothing underneath.
The founders who couldn't raise early and had to go find a paying customer instead got the most important feedback the startup world has. Someone who has no obligation to be nice to you decided your thing was worth money. That's it. That's the whole game early on and most of the ecosystem is set up to let founders avoid finding that out for as long as possible.
A database is a file system when you get down to it. The reason people use them is to abstract up a layer so you can query the data and get the results you want instead of having to iterate through direct reads of a disk, then having to read, parse, and filter what you want from those reads. You could always write code to help do those things direct from disk, but you know what you have just written if you do so? A database!
It would be straightforward, for instance, to implement a lot of the functionality of a filesystem in a database with BLOBs. Random access might be a hassle, but people are getting used to "filesystem-like" systems which are bad at random access like S3.
> You could always write code to help doing those things direct from disk, but you know what you have just written if you do so? A database!
Yes, but that's my point. Why is this not a part of the standard library / typical package with very little friction with the rest of the code, instead of a separate program that the standard library / typical packages provide in an attempt to reduce the friction?
Or are you making the general point that databases already existed prior to the standard libraries etc, and this is just a case of interfacing with an existing technology instead of rebuilding from scratch?
Because a reasonably well optimized database with support for indexes, data integrity enforcement, transactions, and all the other important things we expect from a good (relational) database is complex enough that it takes a rather large codebase to do it reasonably well. It’s not something you slap together out of a handful of function calls.
ETA: look at SQLite for an example — it’s a relatively recent and simple entrant in the field and the closest you’ll find in the mainstream to a purely filesystem based RDBMS. How would you provide a stdlib that would let you implement something like that reasonably simply? What would be the use case for it?
Even if it could, it is a bad idea. How many sob stories are posted to HN about someone building a small startup that is utterly reliant on a 3rd party, and then they crash out and fail when that 3rd party has a problem. And the responses are always the same: "ooh, harsh way to learn that lesson... sorry." AI is no different. It is a 3rd party dependency. It will fail you. You need to have the skills to respond and adapt when those failures occur.
If AI helps you and makes your life easier, great. Use it. If it does 98% of the work for you, that is amazing. But if you could not have done it without AI, then it isn't helping you, it is a crutch. Think about airline pilots. They often (mostly?) just chill and observe while the autopilot does everything. But they can step up, take control, and do everything when needed. Can you imagine flying with a pilot who says, "No, I don't know how to land a plane. The autopilot does that for me." Don't be the software equivalent of a pilot who can't land their own plane.