[Super Simple Explanation] What exactly makes AGI-driven development easier?

When difficult terms keep coming up,
you want to stop reading right there, don't you?

So, first of all,
I will tell you only the most important thing.

AGI-driven development is not about
the 'how-to' of building.
It is about changing 'how you spend your time'.

To put the conventional way super simply

Conventional development generally followed this flow.

1. First, write specifications

2. Have meetings

3. Write specifications again

4. Feel like it's not getting across

5. Fix it

6. Still not finished

At this point, many people are thinking:

1. Invisible losses

→ The day ends just by writing specifications

Writing specifications itself is not bad.

But in reality,

• Writing

• Fixing

• Even after fixing, rewriting it again

The whole day ends with just "writing."

In reality,
it's faster to just see something that works anyway.

② The cost of procrastination

→ Requirement definition meetings never end

"Let's finalize the requirements first."

How many meetings have we had
because of this phrase?

But in reality,

• what we decided changes immediately

• Because it changes, another meeting

• It still hasn't started

We are spending too much time just deciding things.

③ The gap you can't recover from

→ People who build fast are already ahead

Right now,

• explain it verbally

• wait a little

• a working product appears

There are people living in a world where this is possible.

On the other hand,

• write

• it doesn't get across

• rewrite

While doing this,
the gap keeps widening.

4. Small sense of discomfort

→ What you really want to convey cannot be put into words

What I want to convey is,

• this kind of feeling

• this part is a bit off

• something is not quite right

But when you write it in a specification document,

• it becomes rigid

• Long

• The essence disappears

What you want to say and what you can write are different.

5. Unconscious habits

→ The habit of "specifications first"

Why do we write specifications?

The reason is usually this.

• Because that's how we've always done it

• Because it feels safer that way

But that is also
a pattern that doesn't require thinking as well.

6. Decision cost

→ I don't know how to ask for it

"I want you to make this"

Even though I just want to say that,

• How should I write it?

• How much should I decide?

• Scared of making a mistake

As a result, you stop.

It's not because you're not smart.
The system is just too complicated.

7. Avoiding the worst-case scenario

→ The day ends with just busywork

Before you know it,

• fixing

• checking

• fixing again

and the day is over.

Even though, really,

is what you wanted to think about.

8. Self-esteem

→ You wanted to be on the side that thinks

It's not that you hate building things.

But in reality,

• Thinking about the direction

• Thinking about the mechanism

• Thinking about the future

That's what I wanted to do.

9. What others think

→ I want to say, "Can't this be automated?"

I actually think that.

But,

• It seems hard to build

• It seems difficult to ask for

So I can't say it.

10. A concrete vision of hope

→ Just by stating the problem, it takes shape

AGI-driven development is like this.

• State what you are struggling with

• Something that works immediately appears

• Look at it, then fix it

Experience comes before text.

Is AGI-driven development some kind of amazing technology?

No.

What is amazing is this:

That people who think,
can have the time to think properly.

Conclusion

What has been stolen from us until now is:

• Time

• Mental space

• The ability to think

AGI-driven development is
not just for 'smart people'.

It is a system for people who want to think, to be able to think. is what it is.