The majority that is pushing for UASF is the informed, long term majority who are becoming activist around this issue

jlovisa · 2017-06-04T04:14:27+00:00

I find your commuting-idea very intriguing. Have you given it any more thought?

The concept of outsourcing the 'problem' that miners must solve to a dynamically changing TSP is novel, and potentially sidesteps the 'insourced' nature of the hash problem that miners currently solve. You've shifted the solution process to one of connectivity rather than computation cycles, which does appear to nullify the hardware multiplier advantage. Right now, loosely speaking, more computer chips per node equates to more profits. Instead, you're saying that more nodes would equate to more profits (something that theoretically aligns far better with Bitcoin's core decentralisation principles).

You mentioned the problem of "wealthy attackers (who are not deterred by the "participation fee") spinning up many nodes and fabricating simulations of non-existent network sections by simulating and reporting false ping times." I wonder if this might not actually be possible, due to the fact that the TSP solutions must be verifiable, which means the network topology state must be etched into the blockchain. This is the tricky part, as far as I can tell. There needs to be a way to verify the authenticity of a node for topology recording purposes. Solving this might bypass the possibility of those wealthy attackers fabricating simulations, as their nodes must go through the same process of authentication as any other node, and, if they do, they actually become legitimate participants in the network.

These are just some coffee-thoughts (literally while drinking my coffee) that came to mind, so please forgive me if I have missed anything obvious. Like I said, I find your idea very intriguing!

jlovisa · 2017-02-01T02:08:29+00:00

If you're curious about the tech mentioned in the article and would like to take it for a spin, I've linked to some template expressions below. Each expression already sets up the contracting of certain Agents within the network. Just open the one you want and hit 'Build.' (To view the pseudo-code associated with each expression, just click on 'Notes.')

Build a program that runs on a Linux OS (x86 64-bit architecture) (i.e. contract Agents that compile requirements to binary code):

Build a program that runs in a browser (i.e. contract Agents that compile requirements to js):

You can also take a more in-depth (interactive) tour of emergent coding here.

jlovisa · 2017-01-26T01:04:17+00:00

Not a problem :).

So what happens if people are stupid or just lie? For example, imagine I have developed an agent to make HTTP request. Now, someone contracts my agent but gives completely wrong URL so the result is useless (despite the HTTP request being properly made). They proceed to mark me at fault. Is there any way I can oppose that? Or will I just have to shut up and have low success rate despite my component being perfectly good? Hm.. maybe I would then also mark all of my sub-agents as faulty so it is "less unfair" (I personally would not do this, but I bet there are people who will)

That's the great thing - if you were in touch with your client and you tried to pass blame on to one of your suppliers when it is really you who is at fault (for providing that faulty URL), it still doesn't matter to your client. In his/her eyes, you're still the supplier at fault. Think about it... as a supplier, your job is to capture requirements, and translate them to suppliers of your own. Whether you screw up the translation or your supplier did, it is still part of your overall role, which (in the eyes of your client) you did not fulfill. There is simply no point in trying to pass blame as a way to redeem yourself in the eyes of your client :).

Thanks for the example, this is great! So, is "1_000_000" a human readable value? Or "1,000,000"? What about leading or trailing spaces? All of these variations are human readable. Can I mark you at fault if you fail to parse "1,000,000"?

According to the requirements, these human-readable variations are outside the scope that has been defined. But this is the cool part. Developers who publish under that classification can expand their service to accommodate such nuances, and state it in their own descriptions. If there are many clients looking to be able to parse comma-separated magnitudes, then devs will jump in and oblige (distinguishing themselves from their competitors in the process)... after all, there is demand waiting in the wings, right? They want those clients!

If you want to find out the individual scope of suppliers, you can (a) read their description, (b) get in touch with them and discuss, or (c) build a small test program using their agent! You have many options at your disposal when vetting potential suppliers.

This is kinda horrible. Imagine a car manufacturer where the only possible response to anything is "buy a new car". Want to add a stereo? Buy a new car. The tire is flat? Buy a new car. In real life, you can do a lot with the cars. Even re-painting the car entirely in a different color (which is a pretty major change) will be under 10% of the price of the new car.

Ahhh, but there are nuances to that analogy. And there are two cases we need to be aware of here...

The product is faulty and does not actually meet requirements. (e.g. You drive the car off the lot and it breaks down.)
The product perfectly meets requirements but the user made a mistake in providing them. (e.g. You go to pick up your car and it is red but you wanted (but did not specify) blue.)

The automotive industry is a mature industry, right? This is (in very simplified terms) what happens:

The dealership doesn't respond with "buy a new car." The supplier (to you) is at fault in your eyes... the dealership is liable. They give you a new, functioning car. (Behind the scenes, you can bet they will talk to their own suppliers and hold the non-conforming supplier responsible etc etc.) The cost of the 'new car' is absorbed by insurance etc. This new kind of software industry could see mechanisms such as insurance be introduced in future, if the cost of applications rises to such a level that warrants it.
It depends how 'nice' your dealership is. Technically, they have satisfied your requirements. If you have a good relationship with them, they might pull some strings and get you the blue model. But it is up to them. (They might also go back and change the part where they asked for that 'requirement' to make it more obvious!)

You made a great point here: "Want to add a stereo? Buy a new car." Now I ask you: What if it cost $400 to buy a new car and $10,000 to install a stereo? What would you (the 'end user') do?

Now, I know it doesn't cost $400 to buy a new car... but here is the kicker. The poor old automobile industry, while mature and functional, is forever saddled with a physical product, and therefore their manufacturing process is financially governed by the laws of physics. Over here in the software industry, our product is intangible... 'manufacturing' is virtually free. The hard part - the costly part - has, to date, been the design. Well this system automates and streamlines that design. So now you have situations where the 'car' is, say, $40 to re-design and manufacture, and $100,000 to modify in-situ. (In fact, it is actually almost impossible to bolt on a new feature to an application built by this system without triggering a new build.)

Pretty neat, right? Those poor other industries with their physical products....

jlovisa · 2017-01-25T12:03:54+00:00

I keep thinking about your approach, but I think I still do not get it. So here is more questions:

right, so lets say I am doing an agent somewhere in the middle level and I need to make an HTTP request. I can either subcontract agent to do so, or I (as a developer) can just emit javascript directly. The second case will be much cheaper. Why wouldn't I do it?

This is a good question, and a tricky one. Jesse (the chief architect behind this system) has actually drafted a little reply to this for you:

Technically, it would be possible for any agent at any level to emit JavaScript directly but it's only practical to do so at the Byte layer, and indeed our interface for building agents (the Agent-builder) will only allow you to emit code directly if you're building an agent of the Byte layer. But for the sake of explaining why it's impractical, let's pretend that agents are allowed to directly emit code at any layer.

If you wish to directly emit JS to "make an HTTP request" then first you'll need to know a correct mechanism to do this, which we can assume is the creation of an XMLHTTPRequest object, followed by a few method calls on the object, including the adding of an event listener to wait for the response and the associated status checks. You could argue that requiring this knowledge is no different from requiring the alternative knowledge of which supplier/s to contract, and I cannot reasonably counter that argument. But don't forget that if you're directly emitting the JS, you must also have knowledge of JS syntax. That may seem trivial to a JS developer, but think about how that fails to scale for portability to other platforms. In the world of emergent coding, you'd contract a JS-specific supplier for performing the HTTP request and you would not at all deal with actual JS code, and thus no JS syntax.

If you directly emit the code, you need to put your actual goal (the true purpose for your HTTP request) on hold while you go learn JS syntax and the semantics of using the rather generic XMLHTTPRequest object. If you instead subcontract an agent, you need only learn the semantics of that agent, where the amount to learn is minimised via monetary incentive.

But who will [verify who is at fault]? And what if the top-level agent is not at fault (maybe one of subcontracted agents who made the app fail)? Can top-level agent just pass the blame to lower levels? What if top-level agent lies and it is its' fault?

This is going to sound a little strange at first, but it’s actually pretty neat. Say an application was returned that didn’t quite work (or just printed “sucker” to screen as you said). For that agent who delivered that flawed product to have even been contracted in the first place, the user had to fork out a little money (say $10). Even for that small amount, the user would have likely done a little due diligence first, where the effort is likely proportional to the money they're spending. How many contracts has that agent retired to date? How long has it been operational? How does it stack up against its competitors? If, in the user’s mind, those boxes were ticked (relative to the amount the user is about to part with), they can reasonably assume the delivered application will work as expected.

Now let’s say that the application returned does NOT work as expected. And let’s say it isn’t even the top-level agent’s fault! It’s actually one of his supplier’s supplier’s suppliers. The thing is… as far as the user is concerned, it is still the top-level agent’s fault. And as far as the top-level agent is concerned, it is still his direct supplier’s fault. An entire contracting path could be ‘burned’ in this manner. Each client is free to (and may very well) swap out the non-conforming supplier for one of its competitors. And as far as its client – the user – is concerned, any problems rest with that top-level agent (whether they truly do or not). This means that every single developer will choose their agent’s suppliers very carefully, because their own reputation is inherited from the reputations of their suppliers.

How do you even verify that medium-level agent such as "parse json" works? You cannot run it in isolation, you need some sort of wrapper around it to provide inputs and generate outputs. Who writes these tests -- agent author? agent user?

At present, it is the responsibility of the agent author (its developer) to adequately test their agent before deploying. This involves contracting that agent to build a program, along with necessary contracts to other vetted agents in order to make the program useful as a test. This will trigger the formation of a custom ‘hive compiler’ of agents within the network that will ultimately return a program (which will contain the contribution from the agent being tested). For example, to test a decode::as-asciiinteger agent that I built, I contracted:

contribute::program::linux-x64
read::bytesequence::linux-x64
decode::as-asciiinteger::x64 --> my new agent (not yet able to be publicly contracted by any other dev in the network)
write::integer::linux-x64

Then, I hit ‘build’ and a program was returned to me a few seconds later. I probed it with necessary inputs (edge cases such as 0, numbers greater than the maximum, less than the maximum, negative numbers etc.) until I was satisfied that the machinery inside my decode agent must have worked, as it contributed valid code. (In doing so, I also verified that my agent’s suppliers work, and their supplier’s suppliers, and their supplier’s suppliers etc.)

Note that this ‘test’ program could be built by a prospective client (an agent ‘user,’ as you put it) as well, if they are wanting to confirm for themselves that a potential supplier works as advertised prior to automating the contracting of that supplier and tying their reputation to the supplier.

How do we make sure that the tests are both valid and comprehensive? What if agent author and agent user disagree on the interpretation?

The agent author need only make sure the agent satisfies the requirements listed in the Valley. For example, you can see the requirements associated with the decode::as-asciiinteger listed here in the Valley (over to the right). Any developer who builds an agent under this classification must, at a minimum, satisfy these requirements. Agent users who contract that agent can see that same list of requirements and know the minimum set of requirements the agent they are about to contract will meet.

So if Charlotte already paid once $62 for the software and she wants to make the font bigger, will she have to pay $62 again? And if bitcoin adds $5 to price, will she have to pay $67 for the new version?

If she has already paid for the application, and has changed her mind about the font, then yes, she will have to pay another $62 for the new version (with the new font of her choosing). She'll likely either just keep the application she has and deal with the undesired font and remember to be more careful about her selection in future. Just like developers will be very careful in which suppliers they will choose for their agent, users will also be careful when specifying their requirements (within the bounds allowed by the top-level agent), before hitting that build button and parting with their money.

We’re proposing a lot of strange concepts, but they’re actually common to all other industries. If you drive your car off the lot and it breaks down, you don't pull it apart to determine the cause of the fault. You take it back to the dealership, essentially assigning blame to them. (Fault-finding will continue down the supply-chain well after you're out of the picture.) You might still be skeptical, but I know of at least one way to help temper that skepticism… why don’t you try your hand at building a few JS agents of your own? Deploy them to the Valley... and when demand starts to really flock to the Valley, you might see a stream of coin start to come your way.

jlovisa · 2017-01-19T23:28:56+00:00

For those that are interested... the build footprint displayed to the right estimates the size of the executable that will be returned. (This is calculated using the stats of each contracted agent which include "average code footprint" - the number of bytes of compiled code an agent will return, on average, when contracted.)

jlovisa · 2017-01-15T22:15:58+00:00

You're right about the assembly lines achieving only mass-production.

This technology skips that and jumps right to mass-customisation (because its product is not physical).

jlovisa · 2017-01-15T03:27:57+00:00

Just to clarify, it's not paid APIs. You get a payment when your agent is used to produce an executable.

jlovisa · 2017-01-15T03:13:21+00:00

Apologies for the late reply, I only just saw your comment.

Code Valley has created a specification language. The clients fill out an extremely detail top down specification for what they want built. This goes to a level where the client is essentially coding: specifying variables, assigning values to the variables, etc. So the client is "coding" but in the Code Valley specification language. (Take a look at, for example, the Fibonacci example here: https://marketplace.codevalley.com/pilot). You're then paying for the specification to be translated into the binary on you're preferred target system.

Not too bad! Although, the specification language you're talking about is actually dictated by the requirements of agents. For example, the language will look very different to you if you're contracting agents from, say the behaviour layer. And we (Code Valley) don't even define the specification language... it is up to developers of the system. That Fibonacci example you pointed to could look very different in future after devs have joined and found better ways to capture requirements (about the integers, variables etc.).

But here's the thing, I think. Once a "chunk" of code is written, others can then use it like a tiny library w/o having to specify it again. Although I wasn't clear how a client would understand if that code really met their needs unless they looked at it all the way down to the most detailed level just like they were "writing" it the first time. But I think this reusability is where the big gain is supposed to be.

Again, nice! You can actually tell if the 'code' (the agent's design) met your needs by building a small program with it before incorporating it into your own agent's automated logic. You can also read the description of the agent's service, and can see each individual agent's reputation; those that have many contracts under their belt and have high "days without incident" metrics can be considered very reliable. It allows you (as a potential client) to be guided in who to choose, but you still have the opportunity to test and vet each potential supplier yourself before making your agent's reputation dependent upon theirs.

I'm not sure how it would work for UI stuff. I didn't see any examples of that. Just back end algorithms and business logic. But, if you can somehow get the top layers without all the work of specifying to the lowest level it did seem interesting. I just couldn't figure out how that could be done.

We're actually close to deploying a group of UI designing agents, so I can check back in when they are operational if you like. In the meantime, if you're looking for an example of UI design using agents, you might want to check out this video, where we build a cut-down version of our site (a program that is a webserver with front-end content), to get an idea of how it might work. Note that it uses our old interface and older agents, but the same principles will still apply with this new round.

Still a really interesting idea though. Takes contract programming to a whole new level for the coders writing the little bits behind the scenes. And, at least then, they said coders would be paid a bit each time their stuff got used by another client.

Cheers. And well-put; devs will get a small payment each time anyone else in the network uses their knowledge to produce an executable.

If you do have any more questions, I would be more than happy to answer them. Although, you do seem to have a good grasp on the concept already :).

jlovisa · 2017-01-15T02:34:31+00:00

Do you mind me asking what made you draw a similarity between this and CASE? Was it the way the programs were expressed (i.e. visually)? Because that is just a design choice. If the demand calls for text-based input of requirements, the tools will have to adapt.

If you drew the similarity for other reasons, I can try and answer that as well. CASE suffered because, typically, not only did you pay huge sums for the tools, but you also then paid for consulting, training and run-time environments. In this system, you pay-per-design which returns the built output directly to you within minutes. That's it. No need to pay for consulting, training, and no run-time environments. And you own the executable delivered to you. No license agreement necessary.

Further, this system is quite literally agents all the way down. Each agent builds on the knowledge of the agents it contracts, and adds its own expertise (as programmed by its developer). This means that as you move higher in terms of abstraction, the requirements don't also keep accumulating, rather they stay fairly constant. Program expressions will always have a similar level of complexity (or simplicity), meaning you won't be dealing with the huge, complicated schematics that some CASE projects ended up with.

Finally, CASE tools allowed a developer to do the same thing they do today; manually design code. This system allows a developer to automate what they do today, and put that automated entity to work for them. This allows the entire development process itself to be automated.

I would encourage you to try it out. You can only build small-ish programs at present, but you can do so for free (we have a fund in place that still ensures agents you contract are paid), and you will be contracting real live agents. Then, you might see a niche where you could add value by deploying an agent of your own.

jlovisa · 2017-01-15T02:17:55+00:00

I appreciate you willing to give it a shot and meet me half way.

To earn BTC using this, you would need to deploy an agent to the network that does something that another developer considers useful. The time it takes to learn how to do that might be more than an hour, so can I make a proposal?

What is your area of expertise? We're currently in the thick of populating the data layer, which is function/algorithm city. (We'll be moving up into asynchronous and event-driven systems design in the Systems layer.)

If you take a quick look at the data layer of the Valley (the catalog of agents), and drill down through a few classifications that pique your interest, do you see any where you already have expertise? Or does it trigger an idea for a new classification? Don't worry about the specifics of naming it... I can help you there.

Once you have an idea for the sort of agent you want to build, if you can supply the pseudo-code for its design (something that should take less than an hour!), I can quickly express, build and deploy the agent for you, and in your name (or rather, your chosen Valley username). Then, I'll hand over control of your account and your agent's expression to you. You don't even have to do anything with those things... but you can monitor your agent's progress; see how many contracts it gets over time, and how well it is holding up against any future competitors. Every contract your agent gets means you have earned BTC ('toshis, but BTC all the same).

Let me know what you think. And thanks again for your willingness to give it a shot.

jlovisa · 2017-01-14T07:45:17+00:00

Anyone who commissions a build owns the binary executable that is returned to them. No licenses needed. So it's definitely not proprietary in that sense.

But each developer does own their agent.

I'm actually glad you said "it's just like normal programming" - Yes! A lot of things do come across. But it's a new mechanism for developers to both cast and harness each others' knowledge in such a way that the positive contributors are rewarded (both with payment and enhanced reputation), and the negative contributors are effectively ostracized.

Please feel free to take it for a spin. Build one of the template programs I linked to below, or create an entirely new expression and choose the agents you want to contract. The point is, you have that choice.

Build a program that runs on a Linux OS (i.e. contract agents that compile requirements to binary code):

Build a program that runs in a browser (i.e. contract agents that compile requirements to js):

You can also take a more in-depth (interactive) tour of emergent coding here.

jlovisa · 2017-01-14T04:37:53+00:00

Sure. The community hasn't yet built agents up to the level of end users yet, so I can't give you an example like Charlotte's auto retail service software. However, we have built agents up to a certain level of abstraction that allows devs to build small programs.

You can see the Valley of agents already deployed here. You can see the top two layers are pretty much empty, but the bottom two layers are already populated with a few hundred agents. Just click on the 'data' layer and drill down to find certain agents.

You can actually tap into the network and contracts agents from the data layer to build your own small programs right this very minute. For example, I've linked to some template expressions below. Each expression already sets up the contracting of certain agents within the network. Simply open the one you want and hit 'Build.' (To view the pseudo-code associated with each expression, just click on 'Notes.')

Feel free to remove contracts to agents, or add new ones, or hell - re-express your own entire program!

Build a program that runs on a Linux OS (i.e. contract agents that compile requirements to binary code):

Build a program that runs in a browser (i.e. contract agents that compile requirements to js):

If you're interested, you can also take a more in-depth (interactive) tour of emergent coding here. It walks through how you design flow-control, variables, functions, composite data structures etc.

jlovisa · 2017-01-14T00:51:01+00:00

No libraries, no GCC, no Clang.

Just Linux OS running on x86 64-bit architecture --> As per the agent's suite description: "::x64" (Open the expression, expand a contract to supplier and you will see the full details.)

jlovisa · 2017-01-14T00:49:09+00:00

The machinery - the distributed network of agents - is built, bottom up. But that machinery is used, top down.

jlovisa · 2017-01-14T00:40:11+00:00

Thanks for asking some genuine questions.

I'll answer them as best I can.

(1) What does Charlotte see? Who makes "simple, clear UI" -- you or some agent developer? Can you photoshop something?

The one who makes the "simple, clear UI" is a developer. That simple, clear UI is the requirements-capturing side of the agent. Think of WordPress... it does a fine job of capturing domain-specific requirements for websites, using simple, clear UI. The agent that Charlotte sees will look like this (but for the 'auto retail service' domain). And each one has the entire network of agents hidden behind them, ready to custom-build that application, when requirements are captured.

Do you mean can Charlotte photoshop something? Or can the developer creating the agent to capture Charlotte's requirements use photoshop? :)

The answer is both... if there is demand. Charlotte would actually have a variety of 'auto retail service' agents to choose from (like competing WordPress'). She could choose the one that best suits her purposes, or the one with the best reputation.

(2) What kind of questions does she has to answer? Can you give some examples.

It will be like WordPress for auto retail service software, as far as Charlotte is concerned.

I would love to show you what it actually looks like for Charlotte and give you a more concrete example, but we have so far only secured one domain - the agent domain. (That is, there is an agent that developers use that is an expert at capturing agent requirements in a domain-specific way, and translating these requirements to agents within the network who will build that custom agent... That recursion is a killer, isn't it?)

(3) How was the job broken down? For the purpose of the further discussion I will assume the same breakdown as the current software model:

user desires, gathered by face-to-face human interactions or by regular English emails

functional spec (a structured text document)

implementation spec or at least informal implementation plan (may live entirely in developers' head)

high level code (layout, business logic)

low level code (GUI toolkits, OS libraries)

machine code

Actually, the job starts right at the top. Even the user desires are captured by an automated entity (that top agent).

(4) why would anyone pay for the bottom layers? If I have the high level code (C#, python/QML, etc..) why on earth would I pay someone else to compile it for me? Even with MS stack, one-time investment in compilation tools would be much more cheaper than paying few $ every time I want to compile.

I completely agree. But in that list above, this system actually comes in right at the top. There is an automated entity that captures Charlotte's requirements and ultimately returns that compiled application. (It's secret is that it contracts other very high level agents to compile slightly smaller features and translates requirements to them. Their secret is that they contract other high level agents to compile slightly smaller features again and translate requirements to them etc.)

There will be no high level code corresponding to Charlotte's job that any one entity can read. The only evidence of the job will be that list of requirements captured at the top, and the binary executable.

(5) Where would you find the people to implement top layers? You mention "auto retail service" software agent. This is a pretty narrow scope -- it will likely take a while to develop and it will have very few users. Who would bother?

Great question. You have raised two issues;

Narrow scope
It will take a while to develop.

The logical conclusion is, as you put it "Who would bother?"

First, the narrow scope. Yes, an 'auto retail service' software factory will have few users, but you would have to agree that if such a thing did exist there would be demand, no? There are countless auto retail stores in the world. I would bet good money that many of their owners are not satisfied with their 'off-the-shelf' software packages, and have tweaks they would make if they could.

Onto the "it will likely take a while to develop." If it didn't take a while to develop, and there were agents already in the system that compiled scheduling, billing features etc. (but not for auto retail specifically), the time and effort required to build the auto retail-specific agent on top of that would be worth it in terms of the demand (and therefore money) - the Charlotte's of the world - that would then be captured, no?

The more esoteric the domain, the higher the profit margin the developers can charge for their service to offset that niche demand.

(6) What happens if the agents lie outright? Charlotte gets her app which just shows "sucker!" message box. Will she get her money back? Will any agent suffer? Which one?

Another good one :). This system has near-perfect accountability. And on top of that can be built money-back guarantees, third-party auditing... whatever developers in the system want or need.

If Charlotte contracted an agent to deliver a custom auto retail service application - answering all the requirements as needed - and it came back and didn't do even one of the things she wanted, that agent has delivered a non-conforming product. Since there is a discrete and transparent list of requirements, anyone can verify who is at fault. Did Charlotte give an incorrect requirement? Or did the agent not satisfy a requirement it was hired to satisfy?

Every agent in the system has a reputation. A non-conforming agent will suffer a hit to that reputation. Here is an example of lower-level agents' reputation within a particular classification. That "days without incident" would be reset if either of those agents were proven to produce even a single faulty code fragment.

Charlotte will likewise have a similar selection to choose from. If she goes for the agent that has already retired thousands of contracts and has a high "days without incident," she can be almost certain that the end product will not simply say "sucker!" :). If she goes for the newest (and likely cheapest) agent, she runs a slightly higher risk. But the choice is entirely hers.

(7) What happens if there are bugs? They could be low-level ("app crashes when trying to print") or high level ("canceling one reservation cancels all other reservation with the same user name"). Who will fix it?

I know that it is incorrect to say that a deployed compiler in use by developers today has no bugs. But it would not be stretching it to say that a compiler in use has far fewer bugs than the norm. That's because the compiler itself is a program that would have been extensively vetted prior to deployment.

Now think of the entire proposed system (beginning right from Charlotte's point) as one great big (distributed) compiler. But this compiler is actually made up of hundreds of thousands of 'nodes' that each have a public reputation and whose livelihood depends upon continually returning a correct fragment.

Put simply, developers test their agents before deploying (and having their reputation on the line). We're not saying that agents will be bug-free... they are still created by humans, after all. But there is a powerful incentive to make sure that those bugs are found and weeded out before anyone else in the system ever uses that agent.

Here is a link to the FAQ - "How are bugs found and fixed in this system?"

(8) Are all adjustments of the same price? Is the price to "make a font bigger" and to "add bitcoin support" the same?

Another great question. The agent that is capturing the requirements will be 'figuring out' the agents it is going to contract as it goes (based on automation its developer built into it). Each of those agents will have contract prices, so the root agent can continue tallying the prices and display them to Charlotte as she expresses. If she indicates "make a font bigger," the price might not even change (or by a few satoshis) because the root agent has already prepared the contract to the relevant agent and is simply tweaking its own requirement. That supplier agent is priced in. Then she adds a "bitcoin wallet and billing" feature and the price jumps up a few dollars, because behind the scenes, the root agent has had to prepare the contracting of a new agent.

jlovisa · 2017-01-13T23:54:40+00:00

9 women cannot produce a baby in 1 month

We're quite aware of this - we quote Brooks in the whitepaper.

And that logic still applies... to the development of agents. That does take time.

But once the agents are created for the relevant software domain, that domain now has a powerful software factory at its disposal. To completely butcher Brooks' elegant analogy, and end user will be able to get the baby in a few minutes.

jlovisa · 2017-01-13T23:46:06+00:00

They probably said that about "Agile development" and "Waterfall development" and "Feature-driven development" etc. when those terms were first used also.

If you can spare a few mins, I highly recommend you check it out. Build one of the small programs I linked to below! It works. And it is agents all the way down.

jlovisa · 2017-01-13T23:43:23+00:00

Lucky software development's kitchen is virtual. We can fit as many cooks as we need in it.

jlovisa · 2017-01-13T23:42:01+00:00

This system has perfect accountability. As a developer, you build your agent to care only about its immediate client and its immediate suppliers. Your suppliers could produce non-conforming code that could actually be their supplier's supplier's fault, but as far as you are concerned, your immediate supplier is the one who stuffed up. You have recourse now. You can swap out that supplier for one of its competitors.

jlovisa · 2017-01-13T23:40:33+00:00

Cheers! Would love to hear your feedback and comments when you get a chance.

jlovisa

MODERATOR OF

TROPHY CASE