- Unnecessary AI copy throughout the interfaces like "Browse, discover, and manage skils for your agents", "No favorites yet — hover a card and click the star to pin it here", "One execution environment, shared across agents". These instantly read as AI copy and decrease my enthusiasm.
- Inconsistent, AI-sloppy look-and-feel with different typefaces spattered across the interface.
- The session metrics slide looks busy and AI-generated. It repeats 360,014 sessions in one of the cells at the top, but also has a "360K sessions" in the heading.
I don't know if I'm the only one that notices this stuff, or whether others see it too.
Pre-AI the attitude was: if we are going to do something, it is going to use up our precious resources, so we should do it well, because our staff are capable and the marginal cost of doing it well vs. doing it at all is negligible.
Post-AI: we can churn out things quickly, we don’t have to worry about resource allocation, churn churn churn!
Ultimately, it is pragmatic for businesses to behave this way, but it is a shame for those who love the craft. I think we took for granted the beautiful ornate hand carved furniture era of software engineering. We are now in the ikea era.
This is how I realized we truly are in an AI arms race. Literally every app or website or tool I use now forcibly pushes their "AI features" or "AI assistant" on you instead of just letting you use their products the way it makes sense for you. Stripe just confirmed what OP was saying. Poorly built, poorly thought out software is now the norm not the exception any more.
> Surface-agnostic APIs: Kai ships with an opinionated web application and a Slack integration, but the main primitive is the underlying API that powers them both. The agent is a service, not an application, and surfaces are simply customized views into it.
I...kinda get that they built an API that the agent polls. And then Slack or the webapp both invoke the agent? If so, the above paragraph is obscuring the point. Also, why isn't there a diagram showing it? There is a diagram below showing "Execution Environment" below, but that one doesn't show the API. And Kai and "Stripe Product Agents" are parallel paths on it. Does it not call out to this API anywhere?
I doubt if most people these days actually try to understand any of this, or just go "Agents? Cool! Here's some product that's vaguely similar that I like or have worked on!".
And from a sales perspective, that’s probably not wrong.
I think a new (or newly critical) engineering challenge is how to build in a way that keeps a codebase that’s churning out features from crumbling under the weight.
Also their documentation was frequently just straight up incorrect (as in the described json schema for a response was violated. keys missing, different field names, etc.).
But it's been over 10 years, has it improved since then? I'm still in my impression of their stack from back then, although they were decently mature by then as well.
unless you work there how would you know this?
People are always going to judge based on what seems "surface-level". Stuff like legibility also matters just for data comprehension, the AI tic of constantly repeating key numbers all over a presentation or webpage actively hurts legibility.
I think this is where a lot of companies are going to go: on-prem platforms that give various teams access to agents that are as powerful as coding agents, but much more managed and governed.
I'm betting on this with my open source project, Lightspeed: https://github.com/smartcomputer-ai/lightspeed
I think that’s because none of them go past “I’ve set up agents to be orchestrated this way” and that’s about as impressive as “look at my cloudformation template”.
I am finding the opposite to be true with one of my clients. They explicitly want a new channel. The chat-style UI/UX is vastly preferred over their poorly maintained internal tooling.
I suppose if you are Stripe actual, most things would be well designed and more difficult to abandon. Most places aren't like Stripe.
The hard part is bringing everything that matters to the new channel, but it's certainly feasible to do this. I am doing it right now. We will soon be able to delete hundreds of wildly inconsistent cshtml views and related controllers in favor of a single agent tool that applies json patches. This will easily cover 99.9% of use cases. A manual json editor is retained for the rare case where we need some multi-megabyte merge operation.
Happy to be in such good company!
These numbers feel suspicious. How can the increase closed deals be so much larger than the increase in opportunities? Why is twice the sales activity only generating 17% more opportunities?
This kind of internal tooling always creates a window for empire building. The few things I've done that actually mattered at the jobs I've been at have mostly been in excel, and I'm a swe to boot. People don't want another internal tool, they want signal that helps them make business decisions.
Decent tooling is nice, but really over the top tooling can indicate organizational problems like misallocation of resources
https://gp-tree.com/enterprise
Our developer docs for GPTree knowledge engine here https://gp-tree.com/docs/knowledge-api
seems every company that has spare engineering resource all builds such thing internally
What I'm mostly reading is a developer platform and runtime where users can build agents that can run tools and for that you need a secure code runtime, ACL/permissions, easy way to build apps or what cloudflare OS call gadgets. We're betting on this too at https://github.com/windmill-labs/windmill, very curious to see if that's the future for most enterprise and if a model where everyone vibe-code/fork cloudflare OS to their enterprise need is the future, or a more exhaustive/enterprise platform like ours does.
By force or by choice?
Stripe probably WANTS to be opinionated about how their company works with the tools.
1. The whole interface feels way too vibe coded with tons of unneeded stuff. Why does it have a console and snake game built in? Why does it have annoying sounds? Why is it full of AI slop writing? The latter is especially confusing because the first person listed under authors is a "Technical Writer". I guess the interface is the general stripe.dev page not exactly related to Kai but the post definitely is pure AI slop writing.
2. It seems to claim things that might not be substantiated like the following: "When Account Executives use Kai, they produce 2x the sales activity, create 17% more opportunities, generate 26% more revenue opportunities, and close 39% more deals when compared to the same sellers in weeks they don't use it." Correlation is not causation. If sales people have less activity (vacations or sick days etc) then they also wont use this tool much, it doesn't mean all the increase in sales is because of the tool.
3. the post talks a lot about how great this tool is but it describes nearly nothing of value to the outsider who can't access it. What were the valuable lessons learned? What's neat about it? There is not much meat imho.
The whole piece is mostly AI slop.
"Sharing the substrate forces discipline and creates a flywheel: improvements to the execution environment benefit both internal and product agents simultaneously."
No human would write that.
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
That is the reality for most (software) businesses.
I feel this so much. I thought AI would make it easier to get lots of hand-carved ornate furniture; but right now what we are getting looks like the typical Ikea product line -- a bunch of mismatched pieces by a host of different designers with no common underlying design theme or continuity (I'm talking specifically about the looks and design, not the materials).
I have to assume the most common [insert thing] is going to be bad, because more people are amateurs at [insert thing] than are experts. Right?
I have never expected excellence from chatbot generated anything. I have always expected just good enough.
If Ikea furniture were lopsided, ugly, not-quite-properly functional and traded their minimalist design for a Frankenstein hodgepodge of redundant parts.
This is the same problem I see with these Stripe tools. This may not actually be a problem for real users at Stripe.
What's happening right now is more like, we're moving from a hyper-optimized era of just-in-time manufacturing (in software, this is called "Agile", "scrum", "sprints", etc.) to getting our manufacturing outsourced to another country. In software, the "other country" is AI.
I think by any measure that OS/360 would be "high craft".
Possibly not wrong. One scenario that happens over and over again is that we lose a deal because we didn't have feature A. So we build feature A, and we still don't win deals with it. One way this happens is when the competitor has a focus on one part of the market, and we have a focus on another.
Example: We go after SMB, the competitor owns "The Enterprise." Just building A will never break us into the Enterprise part of the market. We have to build an entire strategy around seizing part of the Enterprise market from our competitor. That strategy may or may not include A, but it is definitely more involved than "Build A and customers will come."
if we aren't going to build an entire strategy around "The Enterprise," not only can building A fail to win the business, it may cost us some of our existing SMB business. Every feature our core market doesn't want or need is additional complexity and feature surface area for our customers to absorb. They stop thinking of our product as "tailored for their needs" as it begins to bloat with features they don't need.
And worst of all, the investment in feature A means some other feature—B—that our existing customers have asked for gets punted down-calendar because we're suddenly tearing up our road map and building A because the VP Sales threw a temper tantrum about being unable to close deals without A. This is another way that chasing feature A means sacrificing value for our existing customers who are asking for feature B.
In the case of Stripe, users want one thing, which is to receive correct answers to their questions nearly instantly. And from the sounds of it, that is indeed the case.
[deleted]
No love for Stripe but IMO their documentation feels like a first-class product.
Post AI, I think the bar hasn’t been the same.
It's always possible that in reality they were always a bit less polished behind the scenes though.
the author commented otherwise.
> There might be some AI-isms in there, because agents just can’t help themselves to dump their arcanae in there.
[dead]
The agent has switched a few times, initially NanoClaw, then Hermes, and now Vercel's Eve (maximum customizability).
NextJS/Shadcn web app, postgres db, eve agent layer, MCP tools (over 100 so every single thing can be done by an agent), SwiftUI mobile app, etc.
Integrations with gmail, gcal, gdrive, quickbooks, using mdx for the wiki displays (so we have rich diagrams, 3d models, etc).
We write about it here: https://kznconsulting.com/work/how-we-run-kaizen
Since others are asking: My current goto is pydantic ai and it's been doing pretty well for my use cases.
For example how langchain or whatever else handles subagents and deep research is laughable even today.
So whats the recommendation? Just use pydantic and code everything up yourself. Maybe strands I dont know.
Oh no worries, I'm always happy when library / sdk makers are constantly changing their APIs in-between versions. Why would I not want to spend time updating my code to return to baseline functionality when I could have just built something using the 4-year stable underlying chat completions API instead...?
I use Apache Burr but it's not as good as LangChain. I just don't want to use software whose website has a pricing page if it's not a SAAS.
> No existing tool could handle the data security requirements and specific workflows Stripe needed