Yeah. Exploratory work are much less rigid and they are more throw away. Don’t need to have spec.
Turn that exploratory work to product would be the challenges. It is hard to balance the two
41 karma · joined March 8, 2011
Turn that exploratory work to product would be the challenges. It is hard to balance the two
Background:
We been helping mid-market companies for the past 1.5 years and finally ready to share the internal platform publicly. Yansu (严肃) is a AI coding platform that use spec + TDD to build complex software projects. It is more like a SOP than coding agent. We focus on understanding requirements and checking outcomes against those requirements while iterating the code based on the tests.
Yansu tries to learn as much tribal knowledge as possible. These are things you don’t write down in google doc or Notion. Yansu absorbs these knowledge by continuously talking to users and distilling learning from them.
It's as if a spec + TDD platform had a baby with character.ai.
Why care about requirements? B/c 80% of any software development is understanding requirements and what exactly we want to build. We also focus on outcomes, the only thing that matters. We deliver satisfying outcomes by simulating scenarios and generating tests based on those scenarios. Our agents take that tedious testing part of the code away from others.
We prioritize accuracy over latency/cost, using a mixture of agents (not limited to CC, codex, and etc) to get the job done. We then run through continuous-testing-generating pipelines until all things pass.
What does Yansu mean? “Serious” in Chinese. Just like my favorite artist, Rene Magritte, painting in his kitchen in a suit. I want to give my coding respect and care.
Our goal is to level people up from IC to tech leads, to work on the high leverage work of planning, validating, and educating.
We made a launch video to celebrate human work that builds on all of the creative minds before us. Shoutout to CinemaSings for making this happen.
Enjoy the video and check us out: https://x.com/isoformai/status/1986101032477434129
The job of human is providing teaching via feedback. Your manager does the same thing to you too. And you can distill those feedback into learnable experience for your llm to be better next time.
We are not automating ourselves out of the job, we are changing the nature of the job. From writing to teaching.
Happy to hear your thoughts
openllmetry is focus on engineers, who wants to use this as more of a piping solution and it sits on top of opentelemtry. While opentelemetry is a popular solution. It is just applying a solution to a new problem.
OpenLayers to me is thinking from the ML/AI problems from ground up and while serving the data scientists and probably prompt engineers.
disclosure: I have a repo using the SSPL license
The long term affect is not fun. And not to mention post polio syndrome.
haha, I wish we created spam accounts....Tried to get on the first page by posting to the community slack, but that didn't work :(
Elastic license prevents users to bundle the project as part of their commercial offering. They can use however they want internally.
For BentoML, we will stay with Apache-2, because we see this could be a standard for the industry to use. We are not going to restrict it.
Love to hear your thoughts on our library
For mission critical production usage, I think to use high performance systems/languages is pretty good starting point. With the assumptions that you update your model conservatively(not often), there are enough engineering resources to maintain and 'port' models from python, since most data scientists are trained with python. I think in this type of workload and context, it makes sense use Rust for deployment.
Another type of workload I think it is much more common. It is the experimental projects that data scientists are trying to discover does those have enough ROI to be part of the production system. Those projects and deployments are requiring a quick turn around on iteration cycle. I am not sure Rust or even Swift are good tools, when typical data scientists are not well versed in those. Not to mention, usually in this setting, they don't have a lot of engineering resources they can use. Python is still the go to option for this type of work.
I think the article has the right intention, speed up ML production. For the experimental work setting, I think we can have the cake and eat it too. Data scientists, still use python and generate production ready deployment service without help from engineers.
We create an open source python lib/platform called BentoML(www.github.com/bentoml/bentoml). BentoML makes it easy to serving and deploying ML models in the cloud, from ML model to production API endpoint with few lines of code. You can try it out at this Google Colab notebook(https://colab.research.google.com/github/bentoml/BentoML/blo...)
BentoML works with multiply ML framworks(Tensorflow/fastai/pytorch/etc) and could generate different distribution formats (docker/AWS Lambda/CLI/Spark UDF) for your serving need. We also support custom runtime backend. Feel free to ping me or ask questions in our slack channel. We are pretty active there.
It packages your model for you into a standardized format, that you can use it in multiply serving scenarios online serving with api endpoint, offline serving with spark udf, CLI access or import it as python module. It also helps you deploy to different platform such as lambda, sagemaker and others.
Our value is from model in notebook to production service in 5 mins. Love to hear your feedback on this. You can try out our quick start on Google colab (https://colab.research.google.com/github/bentoml/BentoML/blo...)