Feels like we’re continuing to trend toward deterministic workflows which may actually be okay in 90% of cases. Reality is there’s a lot of unnecessary token burn happening right now. Simple market dynamics will solve that, i.e., when token cost subsidies begin to fade away and we face the true cost of agent applications.
Bingo. All this agentic hype is just people discovering POCs. Yes you can hodgepodge semi-reliable solutions where you don't really know what you're trying to build so you wrap it in a layer than can sometimes approximate logic and decision making, so that you don't have to use logic or make decisions. Amazing.
Sooner or later you have to build the real thing, and the cost and slowness of token-based computation become unacceptable.
“Their relationship with the software is one of pure dependency, and when the software doesn’t do what they need, they just… live with it”
Or, more likely, they churn off the product.
The SaaS platforms that will survive are busy RIGHT NOW revamping their APIs, implementing oauth, and generally reorganizing their products to be discovered and manipulated by agents. Failing in this effort will ultimately result in the demise of any given platform. This goes for larger SaaS companies, too, it’ll just take longer.
And I think it’s less about letting agents modify the product source. That’s more of a platform capability which should also be a requirement for certain types of use cases. All comes back to listening to and / or innovating for customers.
Good engineers are way more important than they’ve ever been and the job market tells the story. Engineering job posts are up 10% year over year. The work is changing but that’s what happens when a new technology wave comes ashore. Don’t give up, ride the new wave. You’re uniquely qualified.
> The downside is that the dryRun-flag pollutes the code a bit. In all the major phases, I need to check if the flag is set, and only print the action that will be taken, but not actually doing it.
What we "want" and what businesses will demand are very different things. I can tell you from 40 years build software, all companies care about is functional software. They don't care about code quality, maintainability, or tech debt. Never seen a single CTO say, "Let's carve out 20% of our sprints for tech debt," even though as architects we recommend something like that all the time.
I think we are both saying similar things here (believe it or not). Sales leaders turnover with surprising frequency - 18-24 months. About the time the sales team tells you what they “want” and you fine tune it, they will be gone. The next person will come in and probably scrap 50-75% of what the prior leader did. New requirements.
Meanwhile, besides functionality, you’ll want/need to plug in the latest and greatest go to market tools for marketing -and demand gen. But… that’ll be a custom effort, too.
Along the way you’ll also realize that you’re missing out on the most common practices in the industry because you built some idiosyncratic tool that only is relevant to your company.
History may very well prove me wrong, but I think you’re underestimating the expertise that underlies these products and platforms. It’s not just code, and the costs of getting it wrong are more than just an engineer’s time. When you waste time in GTM the impacts on the business and valuation are not linear, they’re exponential.
Agreed. We went from “internalise your core business and contract what doesn't give you an edge” to “actually just build everything in-house with AI”. Maybe that’ll be the better option in the end, but for now it looks like tons of wasted effort. 100x developers working on the wrong thing.
I wish I could upvote this more than once. The author gets it, you have to sell outcomes. Not features. Seems like every open source company that doesn’t market an outcome to buyers will face a similar threat. And this particular go to market strategy was “brittle” before AI.
It’s sort of difficult to understand why this is even a question - LLM-based / judgment dependent workflows vs script-based / deterministic workflows.
In mapping out the problems that need to be solved with internal workflows, it’s wise to clarify where probabilistic judgments are helpful / required vs. not upfront. If the process is fixed and requires determinism why not just write scripts (code-gen’ed, of course).
This bothered me at first but I think it's about ease of implementation.
If you've built a good harness with access to lots of tools, it's very easy to plug in a request like "if the linked PR is approved, please react to the slack message with :checkmark:". For a lot of things I can see how it'd actually be harder to generate a script that uses the APIs correctly than to rely on the LLM to figure it out, and maybe that lets you figure out if it's worth spending an hour automating properly.
Of course the specific example in the post seems like it could be one-shotted pretty easily, so it's a strange motivating example.
It seems easier but in my experience building an internal agent it’s not actually easier long term just slow and error prone and you will find yourself trying to solve prompt and context problems for something that should be both reliable and instantaneous
These days I do everything I can to do straightforward automation and only get the agent involved when it’s impossible to move forward without it
reply