This has been what I've been seeing internally within $DAYJOB down to the split between vibe coding / vibe engineering / artisinally crafted code.
The gaps between engineers using the tools and those not are continuing to grow, and I'm curious to see what tools we get to use internally and what we can't... I've been able to demonstrate significant speed up in development time for features with certain tools but the amount of control some of these companies want in contracts are things the company hadn't seen before, and made it too conservative to go in on.
I also see this space changing so much that I don't particularly care for the tools for individuals now as much as I care about the way I share the workload with my team. I need a way to keep everyone up to date and reviewing code without getting brain drained as fast. Review fatigue is real, and it sucks. I haven't really found one that I've liked in that regard and one that a Fortune N company would want to go in on.
> I've been able to demonstrate significant speed up in development time for features with certain tools
Curious to hear more about this. I can't help feeling such an attempt is fundamentally flawed just as software estimates are. Because you're never building the same thing twice.
I wonder if decline of sites like StackOverflow will mean that model quality may crest at some point, at least for newest topics. There are cyclic dependencies in the industry though so maybe everything will evolve in a novel direction. Another possibility is that such sites may become valuable enough as training inputs to start sharing some of the money firehose with contributors.
Cursor may have had incredible growth, but so many companies are getting into these early and obvious products to enhance developer productivity, I don't think they're going to be dominant (independently at least) for much longer.
Google is a direct competitor now, every major model company has an agentic coder, tons of people are putting out small enhancements and useful tools to augment all of these.
In terms of creating a viable business, I would (and have) position myself a step or two away from these obvious solutions. Further out in the ecosystem there's a ton of nuance around specific use cases, programming languages, development and deployment environments; all which will be revolutionized (again) in the years to come.
10 comments
[ 2.8 ms ] story [ 28.5 ms ] threadThe gaps between engineers using the tools and those not are continuing to grow, and I'm curious to see what tools we get to use internally and what we can't... I've been able to demonstrate significant speed up in development time for features with certain tools but the amount of control some of these companies want in contracts are things the company hadn't seen before, and made it too conservative to go in on.
I also see this space changing so much that I don't particularly care for the tools for individuals now as much as I care about the way I share the workload with my team. I need a way to keep everyone up to date and reviewing code without getting brain drained as fast. Review fatigue is real, and it sucks. I haven't really found one that I've liked in that regard and one that a Fortune N company would want to go in on.
Curious to hear more about this. I can't help feeling such an attempt is fundamentally flawed just as software estimates are. Because you're never building the same thing twice.
Google is a direct competitor now, every major model company has an agentic coder, tons of people are putting out small enhancements and useful tools to augment all of these.
In terms of creating a viable business, I would (and have) position myself a step or two away from these obvious solutions. Further out in the ecosystem there's a ton of nuance around specific use cases, programming languages, development and deployment environments; all which will be revolutionized (again) in the years to come.
This is a huge hidden value add of using AI tools - you can vibe code replacements for SaaS dependencies and migrate off them.