Files
kasperhermansen-blog/content/posts/2023-04-08-evolving-software.md
kjuulh 4bb6b0228a
Some checks failed
continuous-integration/drone/push Build is failing
feat: add blog contents
2025-07-31 11:01:22 +02:00

162 lines
6.3 KiB
Markdown

---
type: "blog-post"
title: "Evolving Software: Embracing AI-Driven Development"
description: "Dive into the world of AI-driven software development as we explore a system that evolves with AI capabilities and context. Learn how starting with a minimal viable product and gradually increasing responsibility can lead to AI-managed software systems. This blog post delves into the challenges of context limitations and expansion, and discusses potential solutions and strategies to optimize AI-generated code. Join us as we envision the future of AI-managed software systems and their potential for transforming the software development landscape."
draft: false
date: "2023-04-08"
updates:
- time: "2023-04-08"
description: "first iteration"
tags:
- '#blog'
- '#ai'
- '#software-development'
- '#ai-driven-development'
- '#evolving-software'
- '#GPT-4'
authors:
- "kjuulh"
---
## Introduction
In this post, we'll explore a system of software development that allows for
evolution and greater responsibilities as AI capabilities and context grow.
Unlike emergent AI functions, where native functions interact with AI
capabilities through an interface, this approach enables AI to build and
maintain its own responsibilities based on a set of goals or directives.
## Initial thoughts
The AI generative model/system would have a set of goals and requirements it
would fulfill, it would build the initial version of the code, or spawn sub-AIs
to build capabilities for them.
It would handle requirements as they come in, and may even be set up to
automatically improve the code by updating to newer libraries, improve
performance and create more maintainable code
## Starting Small: A Minimal Viable Product
Let's begin with a single function or unit of work, similar to what you'd find
in a unit test. The AI generative model would be responsible for this function,
but not as a black box. Instead, it would resemble the following:
```rust
enum SomeFunctionError {
...
}
struct SomeModel {
...
}
fn some_function() -> Result<...> {
let resp = call_api().map_err(|e| SomeFunctionError::ServerErr(e))?;
let content: SomeModel = resp.content()?;
return Ok(content)
}
```
As more requirements arise, the generative system can be informed of them,
allowing it to evolve the function or system accordingly:
```rust
enum SomeFunctionError {
...
}
struct SomeModel {
...
}
fn some_function() -> Result<...> {
let resp = call_api().map_err(|e| SomeFunctionError::ServerErr(e))?;
let content: SomeModel = resp.content()?;
log_metrics(content)?; // new
return Ok(content)
}
```
The generative model would automatically refresh its context when it cycles,
allowing developers to directly modify the code without any runtime magic.
## Scaling Up: Introducing More Responsibility
As the capabilities and context of the AI model evolve, abstraction levels can
be increased, allowing each AI layer to manage its own capabilities. The
hierarchy would look like this:
`service has modules which has files.`
Each file maintains its own context and responsibility within a module, which
itself is a single AI instance. The primary AI module can direct and query
sub-AIs for their capabilities, prompting them to fix bugs, add features, and
even spawn new AIs for emerging requirements.
## Interaction: System Level and Public API
Interaction with the AI should be possible both at the system level and via a
public API. Primary engineers can prompt the AI directly, enabling it to update
its goals and delegate tasks to its child systems.
Through a public API like GitHub, the AI would have its own user account,
allowing developers to mention or assign it to issues. The AI would then handle
the issue directly, offering help, closing it, or fixing the submitted bug.
# A Thought Experiment: Real-World Viability
While this concept requires testing in real-world scenarios, tools like AutoGPT
and GPT4All could potentially be adapted for this purpose. The groundwork laid
by AutoGPT makes integration with existing systems like Git, GitHub, and web
search feasible, along with delegation and supervision tasks.
# The Future of AI-Managed Software Systems
An automated AI-managed software system may soon become a reality, and this post
outlines a potential model for incrementally increasing AI responsibility as its
capabilities grow. Although AI models are currently intelligent and capable,
their context and long-term memory are not as mature, making a gradual model
more suitable for implementation.
A practical example will follow as I experiment more.
### Reflecting on the AI Experience
Working with these AI models has yielded surprising results. Initially, i
anticipated that AI would generate obscure and difficult-to-maintain code.
However, the opposite has proven true: AI can create incredibly readable and
maintainable code. The key is providing concise and directed requirements, as
the AI is quite adept at discerning nuances within them and taking appropriate
action.
The primary challenges i face involve context limitations and context expansion
(acquiring new knowledge). The current context for models like ChatGPT or GPT-4
is quite restricted, with a maximum of 32k tokens (around 20k words). This
constraint must accommodate all the directives driving the generative software
system, its acquired knowledge, and any new requirements.
The central issue is the lack of an easy way for AI to gain knowledge without
exceeding its context cache. While GPT could read an entire library's source
code to understand it, doing so would result in a biased perspective based on
that specific implementation. Alternatively, GPT could read a library's API, but
there is no standard method that's general enough for our use case. Developing
an ingestion function for each language, package manager, and documentation
system would be necessary.
A practical solution involves using AI to optimize context for another AI. In
other words, one AI fetches and digests the documentation, then compresses it as
succinctly as possible for another AI to use. While this approach may not be
perfect, as the AI is not specifically designed to optimize for another AI, it
offers a promising workaround.
Long-term storage is another viable option that i plan to explore. However, its
effectiveness in practice and the extent of context it can restore remain to be
seen.