rohan404

For those interested, I created a gem in Ruby for comparing the similarity of images by computing the dhash of an image and then calculating the Hamming distance between the hashes: https://github.com/rohanpatel2602/ruby-dhash

Out of curiosity, how did you find investors to sell to for secondaries?

Disclaimer - I'm a VP E at Engineer.ai

Apologies if it came across as vague. You're welcome to try out our pricing and timeline estimation system if you'd like to get a sense for how it works - it's all public (https://builder.engineer.ai).

That particular tool uses historical data from our user story management system and repository system to glean insights such as average amount of time taken on customizing features, complexity of features and the interactions between them, common errors, developer efficiency by feature grouping, etc. This is all then used as input data into our pricing and timeline estimation system.

Collecting this data was no small feat, we had to build a significant amount of project management and developer tooling in order to get the granularity of data required.

This is also why we're confident that we'll be able to improve our accuracy beyond 90% - as we build more projects, the data collected from that process will feed back into these models.

Disclaimer - I'm a VP E at Engineer.ai

To clarify, while we intend to use AI to solve a variety of different problems, we're not using it for actual code synthesis (ie. building apps). Instead we are leveraging code reusability and programmatic stitching/merging for our software assembly line.

In addition to that, we are leveraging various AI/ML techniques throughout the rest of the product development lifecycle, for areas such as pricing/specing/ideation, infrastructure management/scalability, code reusability itself and matching, creator (developer/QA/design) resource matching, sequencing and dependency prioritization, and more.

Disclaimer - I'm a VP E at Engineer.ai

Apologies for that experience! We're currently working on a new iteration of that site and will be launching it very shortly. Come back soon and let us know what you think.

Disclaimer - I'm a VP E at Engineer.ai

Glad you were able to stop by at Collision! The process today is certainly not as user friendly as we'd like and can be quite time consuming. We're doing a revamp of the particular experience you saw in Toronto to streamline the process and also the ability to create clickable prototypes automatically!

Though we're still developing that tool, we intend to unveil it at WebSummit this year. Hope to see you there and get your feedback on it!

Disclaimer - I'm a VP E at Engineer.ai

All of our project timelines are generated fully automatically. Today we are hovering at around a 90% accuracy on those estimates, and are moving more and more towards solving that last 10%.

We put our money where are mouth is - for example if our system generates a spec with a timeline of 10 weeks and a price of of 10K, and we take 15 weeks, we do not charge more than 10K.

Unfortunately I can't reveal more details of how we generate those timelines automatically apart from the fact that is uses NLP, CNNs, and regression analysis as it is proprietary and core to our business.

Disclaimer - I'm a VP E at Engineer.ai

We're attempting to tackle the problem holistically. That means that we're tackling every single step of the traditional product development process. All the way from how you ideate, price, and spec, to sourcing and managing developers through to QA and infrastructure management.

For example, today, our ideation/pricing/spec tools leverage applied ML, creator management leverages facial recognition for fraud prevention, and infrastructure management uses statistical modelling.

We're trying to make code re-use a repeatable and predictable process rather than just a best practice. Today in the industry it's a purely led by developers, and very often is done solely at their discretion in a manual fashion. We're attempting to platform enforce code reuse, across autonomous distributed teams and products. Apart from just deciding what the optimal building blocks for a project are, the actual assembly or intelligent merging of these building blocks in an automated way is non trivial and mirrors modern automative assembly lines.

Disclaimer - I'm a VP E at Engineer.ai

It's not just one problem we're tackling, it's actually more like 40 small issues that we're working on. You actually named a few right there - static code analysis, automatic UI generation from YAML. I also want to be clear that not all of it is AI or ML. For example how we price and spec out ideas (https://builder.engineer.ai/) is fully automated and leverages NLP and NNs, and how we handle developer verification uses facial recognition. However many of the problems we are going after don't require AI; heuristics based approaches and statistical models can actually have better results in many cases.

Disclaimer - I'm a VP E at Engineer.ai

We've been very transparent with our investors on where we are in the process of creating this platform both pre-investment and post. They actually responded to the WSJ article:

A spokeswoman for Deepcore said it has complete confidence in Mr. Duggal’s vision and team.

A spokesman for Jungle Ventures said it is a proud investor in Engineer.ai and its technology, adding that “the AI landscape is a varied spectrum.”

A Lakestar spokeswoman said it also has confidence in Engineer.ai and its team, adding that “growth in the AI space does not happen overnight.” It said Engineer.ai had been very careful in presenting its technology to Lakestar and other investors

Disclaimer - I'm a VP E at Engineer.ai

Happy to elaborate - in a nutshell what we're trying to do is automate as many parts of the traditional software development lifecycle as we can, and for whatever cannot be automated, put in place the right tooling to allow for repeatable results.

Our thesis is that most applications today have a huge amount of duplication at a code level, and process level. We're trying to use reusable building blocks (well structured libraries, templated user stories, wireframes, common errors, etc.), in order to immediately solve that duplication. That being said, we're not talking about automatic code generation, it's more about being able to assemble these reusable building blocks together at the beginning of a project so you have a better starting point. There will always be customization required for any project however, and that is a human led process.

Apart from actual development, we're also trying to automate processes around project management, infrastructure management, and QA. For example, what we've already been able to do is automatically price and create timeline estimates for a project without any human involvement, determine which creators on our network are best suited for a given project, evaluate and onboard developers on to the network, setup developer environments, and a lot more!

Disclaimer - I'm a VP E at Engineer.ai

You're more or less correct in your understanding, we're trying to get to 80%, and are certainly not there yet. The other thing to keep in mind is that there's a lot more than goes into developing software than just code.

We've already been able to automate problems such as selecting the optimal creators (developers, QAs, designers) for a given project from our capacity network, the ability to price out and estimate timelines for a project (something that takes our competitors 2-3 weeks), onboard and evaluate engineers on our platform, predict, arbitrage and scale cloud infrastructure for our client's projects, along with a bunch of other areas.

There's definitely a long way for us to go, however we have been able to show proven success on these problem areas already.

Disclaimer - I'm a VP E at Engineer.ai

We actually wrote a blog post a little while ago that might answer a lot of the questions I'm seeing here: https://blog.engineer.ai/a-little-bit-about-ai-and-more-stra...

Disclaimer - I'm a VP E at Engineer.ai

AI is certainly not magic, and as an industry we're super far away from what would be considered real AI in the technical sense. That being said, AI has become a catch all term for everything as simple as linear regressions, all the way through to neural networks.

We don't claim to be able to write apps using AI, we're a platform that is trying to use AI and general automation in order to optimize the traditional SDLC. Actual code generation/synthesis is years away in my opinion and there is far more impact that can be had by going after other manual aspects of software development.

Ruby on Rails out of the box gets a lot of bad rep for being slow and non-performant. Has anyone replaced MRI with JRuby or TruffleRuby to mitigate that? Were there any significant "gotchas" with integrating it?

ActionCable is super easy to use out of the box to get WebSockets running, but it's incredibly non-performant. Anything more than 100 concurrent users took the time taken to a send a message to the socket from milliseconds to seconds. Replacing it with the AnyCable gem in conjunction with AnyCable-Go got us to over 1000 concurrent users without a hitch.

I'd say it's more use Rails for all of your standard CRUD operations and then use Go as a module in Rails using Quartz/FFI if you have any algorithms that need to be high performance. Of course you could always go down the microservice route and spin up a Python/Go service for your more intensive data processing modules.

We had huge performance issues with ActionCable that basically made it unusable for more than 100 concurrent users. We considered EventMachine however ended up going with AnyCable in conjunction with AnyCable-Go which got us up to 1000 concurrency users without any performance impact.

It's true that there isn't an official way to use Devise over REST, but then again Devise isn't even the official way to manage auth in Rails apps - it just happens to be the de facto one due to community support. That being said, by using something like devise_token_auth/simple_token_authentication and devise-two-factor you can have a token based auth system with MFA ready in a matter of minutes. Personally, I don't think there are really any back-end frameworks that have an official way to handle auth as it's always based more on community consensus.

To quote the ever popular HTTParty Ruby library: "When you HTTParty, you must party hard!".

Our founder, Sachin, exited Nivio at a valuation of $100m, and used some of the proceeds to bootstrap Engineer.ai.

From my understanding, Nivio was merged into one of the investor's companies.

- Disclaimer, I'm a VP E at Engineer.ai

Beyond Saurabh’s family connection, Engineer.ai has no relationship financial or otherwise with Videocon or Venugopal Dhoot.

- Disclaimer, I'm a VP E at Engineer.ai

I'm now seriously considering adding that Prometheus photo to our press kit ;)

Jokes aside, my colleague @sachmans has posted a comment above that should hopefully answer your question on how we use AI. As for how we define AI, as an engineer myself, I'm a little annoyed by how it's become an umbrella term for everything from basic statistical models to ANNs. Unfortunately that is the reality of it - and so we've consciously decided to use it as an umbrella term for the various applications of ML/NLP/NNs that we use internally.

- Disclaimer, I'm a VP E at Engineer.ai

Well there's a pretty big difference between us the Grid - namely that we don't believe that humans will ever get fully replaced in software development. Instead we're looking to simply automate the repetitive nature of the SDLC in order to bring down the cost and time taken for developing bespoke software. Also, we're super clear that are limitations on the kind of software that our platform can help us automate. We're specifically interested in applications that have a high degree of re-use, and we actually turn away customers who don't fit that model. For example, we'd never build your enterprise ERP system, though we'd be great at building your HR workflow app, or your order management system.

Our platform is actually made up of a collection of tools and microservices including everything from a user story management system (similar to Jira/PivotalTracker), to the assembler itself which stitches components together and creates scaffolding for applications (infrastructure and code). We use AI in a variety of ways throughout this ecosystem (my colleague @sachmans has touched upon a few of those ways above).

The BBC asked us to build their BBC Click Live app. They were launching Click in India for the first time ever, and wanted an application to allow for audience participation. Since their app was relatively simple and was composed of primarily reusable components, we were able to do it a fraction of the price and timeline that it would have taken if it was created entirely by a human team.

- Disclaimer, I'm a VP E at Engineer.ai

You know in all these years that I've worked at Engineer.ai, I never actually made that connection!

I now realize that we clearly we need to fix that page - those logos mentioned are some of the companies that our senior team have come from (hence why it's in the "Our Team" section)! Apologies if it was misleading, I'm getting that updated right away!

- Disclaimer, I'm a VP E at Engineer.ai

Personally, I don't believe anyone will be able to achieve full code synthesis for a very long time. I'm a firm believer that we'll always need engineers in order to code, product managers to help refine customer requirements, and so on. Having been a developer on the front lines for almost a decade, I've always believed that good software development is more akin to art than an exact science ("good code is like poetry"). That being said, I do think a lot of the stuff we end up doing as part of the SDLC is incredibly repetitive from product to product; boilerplate code, setting up basic architecture, etc. Those are the areas that we're trying to automate as much as possible so that humans can focus only on the custom bits.

- Disclaimer, I'm a VP E at Engineer.ai

Blockchain is something we're currently exploring as a way to augment our business in order to deal with complex problems like identity management, royalty payouts, and escrowed payments. Additionally, today we can only work with developers in devshops; in the future we want to expand into the freelancer market. Dealing with freelancers at scale is a complicated proposition, as it's been super hit and miss with a well structured workflow to manage them. We're hoping we can solve that problem with a mix of automation and blockchain.

- Disclaimer, I am the aforementioned VP Blockchain at Engineer.ai

Security is definitely a topic we're super concerned about. There's an interesting tradeoff with using re-usable components - that is, if there's a security vulnerability in one component, then all apps using it are affected (for example the notable npm incident https://www.theregister.co.uk/2018/07/12/npm_eslint/)! The flip side is that one can easily detect and patch all applications affected by that vulnerability. I'd love to have a chat with anyone who has some thoughts on how to deal with this problem more effectively (email is in my description).

- Disclaimer, I'm a VP E at Engineer.ai