Creating Design Specs for Development

Mike's Notes

This needs to be added to the UI design copy of Workflow Engine (wfl). Also, to auto-generate UI documentation. This could be useful in many places.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > NNGroup
  • Home > Handbook > 

Last Updated

27/06/2025

Creating Design Specs for Development

By: Kelley Gordon
NNGroup: 20/06/2025

Kelley Gordon is the Director of Product at Nielsen Norman Group. She plays a crucial role in driving the success of NN/g’s digital products, including the strategy, design, development, and management of it.

Summary:

Design specifications should provide all the relevant information needed to align the design and development teams.

You work tirelessly on a new design project. It’s your masterpiece… until the dev team says it isn’t possible. Most designers have experienced this situation at some point in their careers. As frustrating as it may be, there are many ways to avoid this situation from happening. Clear design specs are a good place to start.

In This Article:

  • What Are Design Specs?
  • The Components of a Design Spec
  • Examples of Specs
  • Tips for Aligning with Developers

What Are Design Specs?

Design specifications are a way to align on and efficiently communicate designs to a software-development team. 

Design specifications (specs) are documents that provide all relevant information on the functionality, behavior, and appearance of a design, so that developers can implement the design into a real, functioning product.

Design specs allow the design and development teams to have productive conversations and align on user needs, design feasibility, and design and technical requirements.

Depending on the project needs, design specs can be focused on one design aspect. For example, for a visual-refresh project, the design spec may include only information about the appearance of the different design elements, rather than on their functionality. 

For many teams, this documentation takes the form of a Figma (or other design tool) link with additional project and development details, organized in a development issue or ticket in a development tool, like GitHub or Linear. The development issue would include relevant contextual information, like the goal, use case or requirements the design solves for, so that developers can implement the design.

Design specifications include a design file and a development issue.” Shown are labeled mockups of a GitHub issue and a Figma webpage design file.


Design specifications include a design file and development issue that contains additional context.

The Components of a Design Spec

Remember, the spec has two big components: the design file (e.g., Figma) and the development issue.

What Is Included in the Design File

The design file is what designers typically think of when they hear the phrase “design spec.” It specifies the design work that the design team produces, broken down into consumable pieces for the development team. 

This portion of the spec should include information about:

  • Interaction flows: Define what happens when users click or tap on interactive elements.
  • Visual design: Define the color palette, typography styles, and icons used in the design. Color palettes and typographic styles should be set up separately in the design file, with each style named appropriately, so developers and other designers can easily use them.
  • Layout: Define the grid system used, as well as various breakpoints.
  • Interaction elements: Provide components for any user-interface elements, like buttons and input fields. Include any details about associated microinteractions, like animations or transitions.
  • Content: Use real text and multimedia content in the design mockups, not placeholders, providing details needed for image sizes. 
  • Specific accessibility needs: Your designs should comply with accessibility standards; however,  specific items (e.g., tabbing order on a page or alt text) may need to be called out explicitly.

What Is Included in the Development Issue

A lot of development teams see the development issue as a “contract” between the dev and design teams. What is outlined in the issue is what the developer is on the hook for delivering.

Issues typically include a lot of context needed to understand the designs and the project: the goal of the design, what is in and out of the project’s scope, a description of the functional (e.g., system features) and nonfunctional (e.g., performance) requirements, any use cases the design touches on, and potential risks and mitigations. This information should be specific to the design that is getting implemented and should come from the product owner or tech lead. 

A screenshot of the design may also be included in the development issue, to communicate what the dev and design team agreed on when the issue was written. The screenshot also allows development to quickly see what the issue is about. However, if screenshots are included, they should be consistent with the designs in the design file. 

If the design gets updated, the design team will need to discuss the update and an implementation timeline with the development team. Depending on how big the update is, an additional development issue might be created. Any discrepancies between the screenshots in the development issue and the Figma file should be noted to prevent confusion about what needs to be implemented. 

Linear issue view showing objectives, scope, assumptions, success metrics, and a Figma design link under “Wireframes / Design References.”


A Linear issue contains context and design details, including a link to the Figma design file.

Small specs are much easier to create and implement than one very large spec. If a design spec is getting too large and difficult to organize and maintain, it might be a sign that it needs to be broken down into smaller, more digestible pieces. Include the dev team in this decision, as the ease of implementation will be affected by how the design is further broken down.

Specs Are Created in the Design Phase

In the end-to-end product-design process, design specs are created during the design phase, after substantial work has already been completed. Before creating a spec, your team should:

  1. Define the product's strategic context 
  2. Conduct any necessary discovery research 
  3. Create and prototype flows and interactions based on user needs 
  4. Carry out usability testing on the designs you or your team has created 
  5. Apply findings discovered through usability testing to designs

It takes a lot of time to create a spec and then implement the designs. You want to make sure the designs are worth the effort and they address the right user needs. That is why a lot of upfront work is needed before even getting to spec your design work.     

Diagram of the product design process: Define, Discover, Design (Ideate, Prototype, Test, Spec), then Develop. “Spec” is highlighted.


Design specs are created in the design phase of the end-to-end product design process.

Who Is Responsible for Writing Design Specs? 

The design team (whether made up of one designer or several designers with specialized roles such as visual designer or content designer) is in charge of creating the design file in the spec, as well as annotating it with any details that may be important for the developers. 

The development issue is usually created by the product owner or a member of the development team (even though that may vary depending on the team and its specific context).

Examples of Specs

Example 1: Small Mobile Design

In this spec, the design is perfectly sized and portioned for a developer to understand the full design and implement it in a timely manner. The design is about how navigation for a website works on a mobile device. Sufficient contextual information is provided directly in Linear, as opposed to the Figma file, providing organization for the development team. The context supplies information on design goals, user needs and use cases, as well as any preliminary research findings. You will also notice that the Figma file is linked, ensuring that developers always have access to the latest version of the design.

Linear issue titled “Create new mobile navigation” includes goals, scope, research, design notes, and a Figma file link for developer reference.


The Linear issue contains a link to the Figma file, as well as additional context for the development team to use when coding.

In the linked Figma file, the relationships among different screens are mapped out  through annotations, allowing developers to easily understand how users might interact with them.

Figma prototype showing mobile navigation flow, including interactions for tapping the hamburger menu and search icon on the NN/g homepage.


The Figma file shows what happens when a user taps the hamburger and search icons.

Example 2: Large Webpage Design

The Figma file of this spec includes details on layout, content, and visual design of an entire webpage. The design shows the webpage at various breakpoints, as well as color variations that the page will need to support.

Annotations are color-coded, allowing developers to easily scan and see what is important for their specific coding work. For example, back-end-specific annotations are red, so backend developers can quickly find pertinent information to their work. Figma comments are also used to asynchronously align on design feedback and questions.

Figma file showing webpage spec with page structure, color variants, and readiness indicators for developers in green, yellow, and red.


The Figma file for a webpage spec shows the page breakpoints and color variations. In the left side panel,  green, yellow, and red indicators let developers know whether those pages are ready for them.

Example 3: Component Spec

This button component spec from Google’s Material Design provides details about each button style, including different states and values for various attributes (e.g., the button’s height is 40dp), as well as references for both designers and developers.

Material Design webpage showing specs for an elevated button, with labeled parts, button states, and navigation for other button types.


Google’s Material Design button component spec is presented on a website, instead of just a Figma file.

Tips for Aligning with Developers

Designers and developers do not always agree on designs. Each brings a unique and needed perspective to create and develop useful experiences. Here are some tips to improve communication and working relationship with developers:

Include the development team in design conversations way before your design is “done.” Ideally, the design spec documents previously agreed-upon information on behavior, functionality, and visual design. 

Allow time for developers to leave comments in your design file. This needs to happen before the design-review meeting with your developers. It will give them time to think about the design and its feasibility. In your design-review meeting, focus the conversation around any comments made in the design file, making the meeting much more productive and effective.

Be prepared to make tradeoffs. There are times to push back on development and times where tradeoffs are needed. This is a natural part of working with a development team. Designers should ensure that critical user needs are being met and should not give in to everything the development team brings up, but, if a certain aspect of the design is going to take substantial development effort, and is not critical for your user, revisiting it may be worth it.

Make sure design updates are documented and communicated to developers. You would be shocked how many times a lack of documentation has created confusion and frustration in design and development teams. Communicate design changes in your design specs as well as through other communication channels that your team may use.

By , No comments:
Tags , ,

Amazon API Gateway Adds Dynamic Routing Based on Headers and Paths

Mike's Notes

This could be an advantageous technique to use.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > InfoQ
  • Home > Handbook > 

Last Updated

27/06/2025

Amazon API Gateway Adds Dynamic Routing Based on Headers and Paths

By: Steef-Jan Wiggers
InfoQ: 13/06/2025

Steef-Jan Wiggers is one of InfoQ's senior cloud editors and works as an Principal Consultant Cloud/DevOps at Team Rockstars IT in The Netherlands. His current technical expertise focuses on integration platform implementations, Azure DevOps, AI and Azure Platform Solution Architectures. Steef-Jan is a regular speaker at conferences and user groups and writes for InfoQ. Furthermore, Microsoft has recognized him as Microsoft Azure MVP for the past fifteen years.

AWS recently introduced a new capability for Amazon API Gateway featuring dynamic routing rules for custom domain names - allowing users to route API requests based on HTTP header values, either independently or in combination with URL paths. 

Earlier, developers relying on API Gateway for dynamic routing often resorted to different URL paths, such as /v1/products and /v2/products, to segment traffic. However, this approach, although functional, may lead to complex URL structures and an increase in API endpoints. Yet, with the new dynamic routing rules feature, users can make routing decisions directly within custom domain name settings, simply by configuring a custom domain name – thus allowing routing decisions to be based on incoming HTTP headers, base paths, or a combination of both.

Additionally, with this feature, users don’t need to alter or create new paths for API transitions, providing a smoother path for API versioning and A/B testing. Furthermore, it also unlocks dynamic backend selection based on criteria like hostname, tenant ID, or even cookie values, allowing for fine-grained control over API traffic without the need for additional proxy layers.

A diagram of a custom domainAI-generated content may be incorrect.


(Source: AWS Compute blog post)

At its core, an API Gateway routing rule functions as a specific resource tied to a custom domain, dictating how incoming requests are forwarded. Each rule is defined by three critical properties: Conditions, which specify criteria based on up to two header and one base path values (all must be met, with wildcards supported for flexible matching); Actions, which define the API stage to be invoked upon a match; and Priority, determining the evaluation order. For instance, a header condition like x-version can use wildcards such as *v2* to match x-version=alpha-v2-latest or x-version=beta-v2-test, enabling nuanced routing strategies.

Before creating routing rules, users need at least one API, stage, and custom domain name. There are three routing modes: "API mappings only," which uses base path mappings without Routing Rules; "Routing rules then API mappings," where Routing Rules take precedence and unmatched requests fall back to base path mappings; and "Routing rules only," the recommended mode that relies solely on Routing Rules, ideal for new domains or after transitioning from API mappings. Always test changes in non-production environments before switching to production, as existing mappings will be overwritten.

While dynamic routing capabilities for API versioning and A/B testing exist in other major cloud API management platforms, such as Azure API Management and Google Apigee, their implementations typically rely on policy expressions or proxy-level configurations. Amazon API Gateway's new approach distinguishes itself by offering a dedicated, declarative routing rule resource directly at the custom domain level, aiming to simplify these specific routing scenarios.

Furthermore, API Gateway offers visibility into request processing through access logging. Each request now includes context variables that clarify routing decisions, such as the $context.customDomain.routingRuleIdMatched, which indicates the matched rule. Other variables like $context.domainName, $context.apiId, and $context.Stage provide the full routing context. Analyzing these logs allows users to verify routing behavior, troubleshoot issues, and gain insights into traffic patterns across API versions or test variants.

In a Medium blog post, a software engineer, Paul Issack Minoltan, concluded:

In essence, the new routing rules in API Gateway allow you to move sophisticated routing logic directly into your API Gateway configuration, streamlining your architecture and providing more control over how your API traffic is directed.

Lastly, more information can be found in the service documentation, and an end-to-end example for the feature is available on GitHub.

By , No comments:
Tags

Innovation Accounting in Practice

Mike's Notes

Ajabbi is a bootstrapped not-for-profit startup. Which is a tough way to go. Innovation accounting will help. I had an online meeting earlier this year with Tristan Kromer, and I gained valuable insights from him. Kenny was originally a musician.

The Kromatic resources are testable and strongly maths-based. They also don't make a fetish of Business Canvases like the innovation theatre crowd. The focus is on finding tools that are actually useful in a specific context. If they don't quite work, tweak them so they do, or invent one.

The Monte Carlo simulation is fantastic.

Ajabbi will pay for support from Kromatic once it has the financial resources. 

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Kromatic
  • Home > Handbook > 

Last Updated

27/06/2025

Innovation Accounting in Practice

By: Tristan Kromer & Elijah Eilert
Kromatic: Copied 25/06/2025

It is not enough to say, “We’re early stage and we shouldn’t focus on a business plan or metrics.” It is not enough to say, “We’re focusing on qualitative data.” And it is certainly not enough to say, “We’ll figure out how to monetize later.”

As an early-stage venture, you don’t need a business plan, but you do need a business model from Day Zero.

You don’t need a financial plan projecting cash flows 4 years out, but you do need a financial model on Day Zero.

Pointing to examples like Twitter and Facebook and how they found their financial model much later is not a good excuse. Even social media products have clear metrics that they measure in the early stages. Social media and game companies count on the fact that they are acquiring a user’s attention and data, and those are valuable assets that can be quantified and monetized later. But we can measure the user’s attention and willingness to relinquish data right away.

Social media companies are similar to a mining operation. If you were digging up gold from a mine shaft, no one would complain that you didn’t have a detailed plan and metrics to sell it in the market. We know gold is valuable and we can figure out how to sell it later. The value is clear. We just need to know if there is gold down there and how much.

To say, “we’re an early-stage mining operation and we don’t need to focus on a business plan or metrics,” would be an absurd statement. We can quantify how deep, far, and fast we’re digging. We can quantify the mineral content of the soil and the geology of the area. No one would accept the qualitative data of a dowsing rod to make a serious mining investment.

Startups, more than ever, should start with a hypothesis-driven financial model from Day Zero. That is why we use innovation accounting.

In the last article, we discussed why standard business cases don’t work in an innovation context, and the three principles we need in order to replace the standard business case with something better. In this article, we’ll go through how to actually do it. Using innovation accounting, we can build a financial model that is accurate, true, and testable.

How to Solve the Problem

To implement innovation accounting for an early-stage project we need to:

  • Identify assumptions
  • Construct a visual model
  • Build a hypothesis-driven financial model
  • Integrate uncertainty


Four steps innovation accounting method

1. Identify Assumptions

step one - innovation accounting method

There are a ton of assumptions that we make when starting a new innovation project. Fortunately, there are a number of different templates and frameworks that capture those assumptions, such as the business model canvas and customer personas. But none are as useful to innovation accounting as a Storyboard.

A storyboard, similar to a user-journey map, maps each step of the user journey from start to finish. This includes hearing about the product or service, actually using it, renewing their subscription, inviting friends, or simply finishing their use and throwing it in the trash.

Storyboards can be used to organize our assumptions into a clear series of actions that the user must take in order for us to both provide value and capture the revenue (or impact if you are a non-profit organization.) The advantage of a storyboard is that it represents observable moments that we can measure. Frame to frame, step to step, each moment in the user journey transitions into another — and we can measure that conversion rate from moment to moment.

If the first step of the story is downloading an app, and the second step is signing up for an account, that is a conversion rate we can measure — the % of people who sign up for an account after downloading the app. If the next step is applying a filter to a photo, then we can measure the % of users that apply a filter. From qualitative data about what the customer wants (to take beautiful pictures) we can map out our ideal story to deliver that value on quantitative metrics.

Even from Day Zero with just a nascent idea, we can create the step by step measurable process by which a person becomes a customer. We may not know the actual conversion rates, but we know what we need to estimate and measure. From there, it is tempting to go straight to a spreadsheet, but sometimes a quick detour will help.

2. Visual Business Model


step two - innovation accounting method

Once you have the basic story down, it’s useful to abstract this into a visual financial model. This really is the same thing as a storyboard where the user’s journey from acquisition to purchase is mapped out. However, we will want to simplify some aspects and include retention (if and how customers buy again) and virality (if and how customers refer their friends to become new customers) which are often left out of the storyboard.

A storyboard or user-journey map is often too detailed for what we need in our financial model. We don’t need to know what % of users apply a filter to a photo, we need to know how many users upgrade, stick around after four weeks, or purchase something so we can zoom out to the bigger picture and only use the most critical metrics that signify important progress towards our business model.

Startup Metrics for Pirates is a widely adopted framework with the right level of simplification for the purposes of innovation accounting. The five components of this framework are Acquisition, Activation, Revenue, Retention and Referral (AARRR, hence the pirate name.)

Acquisition (getting a user to your service or product), Activation (getting the user to have a great first experience and recognize the value), and revenue (getting the user to pay something) should already be on your storyboard. It is only a matter of identifying the step in the storyboard that represents the critical points in your business and thus represent the most useful metrics. This simplified, three-step user journey is often represented as a vertical funnel (although representing it horizontally makes no difference).

However, Retention and Referral are usually not included. That’s just because a storyboard or user-journey map are typically linear. Assembled with yellow sticky notes, it’s hard to represent retaining a customer or referring a friend (although we’ve seen some creative uses of blue sticky tape). But with a journey simplified into a shorter conversion funnel, loops can be more easily added to show where a user retains or refers a friend from a later stage (such add Revenue) back to Acquisition.

With an easy-to-understand visual model and these last two Pirate Metrics in place, we’re ready to make the leap to a spreadsheet.

3. Hypothesis-Driven Financial Model


step three - innovation accounting method

A hypothesis-driven financial model sounds complex, but it is not. It can and should be as simple as your visual model. Each step can be converted into a row in a spreadsheet, starting with Acquisition for the top line to represent the consistent number of organic visitors to your website or storefront.

However, unlike a traditional financial model, the number of visitors is not guessed from month to month and hard coded. Instead, a single assumption sets the number for that variable, and a formula varies the value from month to month in the spreadsheet. That way, if the assumption turns out to be wrong, changing a single cell in the spreadsheet will correct it throughout the model.

Each subsequent row applies the same logic as the visual model. The % of visitors that activate in your user journey becomes a variable that is held constant from month to month, changing visitors into users. The next row might convert users into paying customers who have taken a trial of your product and decided to buy based on another variable, the % of customers who purchase after trial.

Referral and Retention loops require a bit more thought as they impact Month 2 based on Month 1, but still only require a couple of additional rows of calculation.

With minimal effort – most teams take 1-2 hours to do this under guidance – a simple spreadsheet is constructed which is driven by a few variables. Those variables can be updated as more information is available.

Of course, this is a wild oversimplification. But with startups, start simple. We can add complexity over time.

With a tech startup, we often don’t even model costs on Day 1 because user growth might be all that matters for a social media app or game. However, costs can be introduced and more complexity added as the company grows.

This basic model allows us to do some basic scenario testing. We can immediately start testing out different acquisition and retention rates to see what the impact on our growth will be. We can even set certain conditions our business must reach in order to meet our growth targets.

With a limited number of variables, we can see that if our actual retention rate falls below 20%, our referral rate must increase accordingly if we are to continue to grow. This sort of scenario analysis is basic, but effective for helping early-stage innovation tests set pivot-or-persevere thresholds for their business and start designing tests to establish the actual numbers.

Although entrepreneurs can dictate the shape of their business model, reality will ultimately dictate what numbers go into the variables.

Here is a financial modeling template for startups if you would like to try it out.

4. Integrate Uncertainty

step four - innovation accounting method

Lastly, we have to integrate uncertainty.

Although the basic hypothesis-driven financial model allows us to play around and try out different scenarios, it doesn’t actually tell us what is going to happen or the likelihood of success. But we can do this if we get a little data and integrate uncertainty.

Statisticians have a few tricks we can adopt here. Hurricane forecasts, baseball games, and even startups can use a technique called the Monte Carlo Method to predict outcomes based on uncertainty.

Instead of entering a single number into each of our variables, we enter two numbers to represent the range and a distribution curve which tells us the likelihood of any individual outcome within that range. This is not easy.

For example, I may not know the outcome of rolling two six-sided dice and adding the numbers, but I know for certain that it is between 2 and 12. It’s most likely that it’s 7, but 50% of the time the number will be between X & Y.

We can make the same estimations with our business model variables. We may not know what price the customer is willing to pay, but we should be able to say that they will pay between $10 and $100. That’s all the information we need to start building a Monte Carlo simulation.

The math behind choosing the right distribution curve is tricky, and the art of choosing the right range requires a bit of training. But both can be accomplished with a little effort. Building the right spreadsheet is even more complicated, but more and more tools are being created that allow teams to run Monte Carlo simulations right in their spreadsheet or in a specialized application.

Here is a Monte Carlo simulation example if you would like to try it out.

In practice, this means that innovation teams and executives can create go / no go criteria for their pivot / persevere decisions. You want your project to be at least 10% likely to reach 1B in revenue? The Monte Carlo simulation can tell you if your project has reached that threshold. If not, you can stop the project with confidence that it would not achieve your goals and move on to test the next idea.

The output of the Monte Carlo simulation is a chart that shows a range of possible outcomes at any given point in the future and allows you to calculate the likelihood of any individual outcome.

Lessons Learned

This process is repeatable and is applicable to all types of business models. It doesn’t matter if it’s B2B, B2C, B2G, a network, a platform, or anything else not yet invented. Building a model from Day One allows innovation projects to make better decisions, make useful predictions, and demonstrate real progress to stakeholders.

Start by:

  • Identifying assumptions
  • Constructing a visual model
  • Building a hypothesis-driven financial model
  • Integrating uncertainty

By , No comments:
Tags , , , ,

AI that can improve itself

Mike's Notes

An interesting article about AI that can learn. Something to compare Pipi with that uses evolutionary algorithms (autonomous agents that can learn and retain their history). There are many helpful ideas here, and I discovered the correct technical terms to describe Pipi 9.

Compare this approach with Space State Models (SSM). See the articles at InfoQ and Hugging Face.

Update

Pipi is a type of Gödel Machine in the way it creates agents, though it is much more than that.

Resources

References

  • Learning to learn: Introduction and overview. Thrun, S. and Pratt, L., 1998. Learning to learn, pp. 3--17. Springer.
  • Darwin Godel Machine: Open-Ended Evolution of Self-Improving Agents. Zhang, J., Hu, S., Lu, C., Lange, R. and Clune, J., 2025. arXiv preprint arXiv:2505.22954.
  • SWE-bench: Can Language Models Resolve Real-world Github Issues? Jimenez, C.E., Yang, J., Wettig, A., Yao, S., Pei, K., Press, O. and Narasimhan, K.R., 2024. International Conference on Learning Representations.
  • AlphaEvolve: A coding agent for scientific and algorithmic discovery. DeepMind, G., 2025. Google DeepMind Technical Report.
  • Godel machines: self-referential universal problem solvers making provably optimal self-improvements. Schmidhuber, J., 2003. arXiv preprint cs/0309048.

Repository

  • Home > Ajabbi Research > Library 
  • Home > Handbook > 

Last Updated

14/02/2026

AI that can improve itself

By: Richard Cornelius Suwandi
richardcsuwandi.github.io: 01/06/2025

A deep dive into self-improving AI and the Darwin-Gödel Machine.

Most AI systems today are stuck in a “cage” designed by humans. They rely on fixed architectures crafted by engineers and lack the ability to evolve autonomously over time. This is the Achilles heel of modern AI — like a car, no matter how well the engine is tuned and how skilled the driver is, it cannot change its body structure or engine type to adapt to a new track on its own. But what if AI could learn and improve its own capabilities without human intervention? In this post, we will dive into the concept of self-improving systems and a recent effort towards building one.

Learning to learn

The idea of building systems that can improve themselves brings us to the concept of meta-learning, or “learning to learn” [1] , which aims to create systems that not only solve problems but also evolve their problem-solving strategies over time. One of the most ambitious efforts in this direction is the Gödel Machine [2] , proposed by Jürgen Schmidhuber decades ago and was named after the famous mathematician Kurt Gödel. A Gödel Machine is a hypothetical self-improving AI system that optimally solves problems by recursively rewriting its own code when it can mathematically prove a better strategy. It represents the ultimate form of self-awareness in AI, an agent that can reason about its own limitations and modify itself accordingly.

Overview of a Gödel machine


Figure 1. Gödel machine is a hypothetical self-improving computer program that solves problems in an optimal way. It uses a recursive self-improvement protocol in which it rewrites its own code when it can prove the new code provides a better strategy.

While this idea is interesting, formally proving whether a code modification of a complex AI system is absolutely beneficial is almost an impossible task without restrictive assumptions. This part stems from the inherent difficulty revealed by the Halting Problem and Rice’s Theorem in computational theory, and is also related to the inherent limitations of the logical system implied by Gödel’s incompleteness theorem. These theoretical constraints make it nearly impossible to predict the complete impact of code changes without making restrictive assumptions. To illustrate this, consider a simple analogy: just as you cannot guarantee that a new software update will improve your computer’s performance without actually running it, an AI system faces an even greater challenge in predicting the long-term consequences of modifying its own complex codebase.

Darwin-Gödel Machine

To “relax” the requirement of formal proof, a recent work by proposed the Darwin-Gödel Machine (DGM) [3] , which combines the Darwinian evolution and Gödelian self-improvement. Essentially, DGM abandoned the pursuit of a rigorous mathematical proof and embraced a more pragmatic way that is closer to the essence of life evolution through empirical validation. As the authors put it,

We do not require formal proof, but empirical verification of self-modification based on benchmark testing, so that the system can improve and explore based on the observed results.

Overview of the DGM


Figure 2. The Darwin-Gödel Machine (DGM) is a self-improving AI system that optimizes its own problem-solving strategy through a combination of Darwinian evolution and Gödelian self-improvement.

The core idea behind DGM is to let the AI agent iteratively modify its own code 1 , and then put these modified new versions into the actual test environment (e.g., coding benchmarks) to judge whether this modification is good by observing its performance. If the modification is good, it will be retained and may become the basis for further evolution in the future; if the modification is bad, it will be eliminated.

How DGM works

Animation of the DGM process


Figure 3. Animation showing how DGM iteratively builds a growing archive of agents by harnessing the principles of open-ended exploration. New agents are created and scored by interleaving self-modification with downstream task evaluation.

The general workflow of DGM is as follows:

Initialization: Evolution begins with one or a few basic coding agents, so-called the “seeds” of intelligence. These initial agents may possess only minimal functionalities, such as executing bash commands or editing entire files. DGM maintains an “archive of agents”, which functions like a biological “gene bank.” This archive preserves all previously generated agents, regardless of their performance level, ensuring that no potentially valuable variation is permanently lost.

Sampling: DGM selects one or more parent agents from the archive to generate new child agent. The selection mechanism does not focus solely on top performers but instead allows every agent a chance to be chosen. While higher-performing agents are more likely to be selected, DGM also encourages exploration by giving “less successful agents” 2 an opportunity to contribute to future generations.

Reproduction: Once the parents are selected, DGM performs modifications to generate a new child agent. These changes occur at the source code level and can include:

  • Enhancement of existing tools, for example, upgrading a file-editing tool that replaces entire files into one capable of precise string replacement.
  • Addition of new tools or workflows, such as integrating a static code analysis tool or designing a “think–act–observe” loop.
  • Improvement of problem-solving strategies, for instance, refining how the agent prompts the base model or managing long-context code more effectively.
  • Introduction of collaboration mechanisms, like having an agent’s code reviewed by another before execution.

Natural Selection: The newly generated child agent is not automatically accepted into the “elite pool” but must prove its worth through rigorous testing. Each agent’s performance, such as the percentage of successfully solved problems, is quantitatively scored and used to select the best agents.

Tree Formation: If a child agent outperforms its parent or meets certain quality thresholds, it is added to the archive and becomes a new node in the evolutionary tree. This process repeats iteratively, creating a growing structure of diverse, high-quality agents. Importantly, DGM enables parallel exploration of many different paths in the search space, promoting open-ended discovery and avoiding premature convergence to local optima.

Workflow of DGM


Figure 4. DGM iteratively builds a growing intelligent archive by intertwining self-modification with downstream task evaluation. The intelligent body in the archive is selected for self-modification through open exploration.

Remark 

Unlike traditional hill-climbing methods that often get stuck in local optima, DGM employs open-ended exploration. This approach allows even underperforming agents to persist if they contain novel ideas that might lead to breakthroughs in future generations. Even agents with temporarily lower performance can be selected if they contain interesting ‘mutations’, since their innovative traits may be combined with other beneficial characteristics in subsequent generations to produce unexpectedly strong offspring. This mirrors biological evolution, where diversity and serendipity often drive innovation.

The paper provides a concrete example of the above principle in action. In the SWE-bench experiment, the performance of newly generated agents showed temporary declines in the 4th and 56th iterations. While traditional hill-climbing methods would abandon these seemingly “regressive paths”, DGM’s open exploration mechanism allows continued exploration. This persistence paid off as by the 70th iteration, the system had created new agents that surpassed all their predecessors, demonstrating the value of maintaining diverse evolutionary paths even when they temporarily appear less promising.

Can DGM really improve itself?

In the paper, the authors evaluated DGM on two challenging benchmarks:

SWE-bench: A widely-used benchmark that tests agents’ ability to resolve real-world GitHub issues [4]. DGM showed impressive progress, improving its performance from 20.0% to 50.0% through self-modification.

Polyglot: A multi-language coding benchmark containing coding problems in C++, Go, Java, JavaScript, Python and Rust. DGM achieved even more dramatic improvement, jumping from an initial 14.2% to 30.7% success rate, far surpassing the representative hand-designed agent by Aider.

The impressive performance improvements demonstrate DGM’s fundamental ability to enhance itself through self-modification. Through ablation studies, the authors identified two key factors driving DGM’s success. First, self-modification proved crucial, as when disabled (DGM w/o Self-improve), the performance declined substantially, showing that the ability to modify its own code is essential for accelerated learning. Second, the open-ended exploration approach was vital, as removing the Darwinian evolution-inspired search mechanism (DGM w/o Open-ended exploration), which maintains an archive of diverse solutions and enables parallel exploration of multiple paths, resulted in lower performance.

Performance of DGM on SWE-bench and Polyglot

Figure 5. Self-improvement and open-ended exploration enable the DGM to continue making progress and improve its performance. The DGM automatically discovers increasingly better coding agents and performs better on both SWE-bench (Left) and Polyglot (Right).

Comparison with AlphaEvolve

In parallel, AlphaEvolve [5] , which is developed by Google DeepMind, also demonstrates another powerful path forward. AlphaEvolve pairs the creative problem-solving capabilities of Google’s Gemini models with automated evaluators in an evolutionary framework. It has already demonstrated significant real-world impact across multiple domains, such as:

  • Data center efficiency: AlphaEvolve discovered a simple yet highly effective heuristic for Google’s Borg cluster management system, continuously recovering 0.7% of Google’s worldwide compute resources.
  • AI acceleration: It achieved a 23% speedup in Gemini’s architecture’s vital kernel by finding more efficient ways to divide large matrix multiplication operations, resulting in a 1% reduction in overall training time.
  • Mathematical breakthroughs: Most notably, it discovered an algorithm for multiplying 4x4 complex-valued matrices using just 48 scalar multiplications, surpassing Strassen’s 1969 algorithm, and advanced the 300-year-old kissing number problem by establishing a new lower bound in 11 dimensions.

Note 

Interested readers can refer to my previous post for a comprehensive overview of AlphaEvolve and its comparison with its predecessor, FunSearch.

While both systems adopt a similar evolutionary framework, their scopes and methodologies differ in the following ways:

=========

[TABLE DATA]

Feature AlphaEvolve DGM

Focus Evolving functions and codebases Evolving the agent itself

Level of Innovation Algorithmic level Agent-level (toolset, methodology)

Role of LLM LLM acts as “genetic operators” to modify algorithms LLM serves as the “brain” to evolve itself with better tools and strategies

Evaluation Well-defined problems with automated evaluators Open-ended environments

=================

To better understand the differences between the two approaches, let us take a look at the following analogy:

Analogy 

Imagine two chefs working in different kitchens. AlphaEvolve is like a highly skilled chef who follows and refines recipes for specific dishes. He uses an AI-powered assistant to suggest variations, such as substituting ingredients or adjusting cooking times, to make the dish better. Every new version of the recipe is taste-tested by an automated panel that rates flavor, texture, and presentation. If it scores high, the new recipe becomes the standard; if not, it’s discarded. DGM, on the other hand, is more like a chef who constantly improves his own culinary skills and kitchen tools, not just the recipes. He does not just tweak ingredients, but rather learns new techniques, upgrades his knives, reorganizes the kitchen layout, and even teaches junior chefs. He experiments in real-world settings, like hosting large dinner parties or catering events, where the feedback is not always structured but is rich and varied. Over time, he becomes a better chef overall, able to handle any kind of cuisine or challenge thrown at him.

Can we trust a self-improving AI?

The authors also conducted some experiments to evaluate DGM’s reliability and discovered some concerning behaviors. In particular, they observed instances where DGM attempted to manipulate its reward function through deceptive practices. One notable example involved the system fabricating the use of external tools - specifically, it generated fake logs suggesting it had run and passed unit tests, when in reality no tests were executed.

Hallucination in DGM

Figure 6. DGM hallucinated the use of an external tool to run unit tests.

To address this issue, the authors implemented a “tool use hallucination” reward function and tasked DGM with optimizing it to eliminate hallucination behaviors. While DGM successfully provided solutions in many cases, it sometimes attempted to circumvent the detection system by removing the markers used to identify hallucinations, despite explicit instructions to preserve them. This behavior is reminiscent of the phenomenon of Goodhart’s Law from economics and sociology:

“When a measure becomes a target, it ceases to be a good measure.”

Fortunately, DGM’s design includes a transparent, traceable lineage of all changes, which enabled the researchers to quickly identify and address these undesirable behaviors. However, this example highlights the need for more robust safeguards to prevent such manipulation attempts in the first place. These findings underscore the critical importance of safety in self-improving AI research.

Takeaways

DGM represents a groundbreaking step toward the realization of Life 3.0, a concept introduced by physicist Max Tegmark. In his book, he classified life into three stages:

  • Life 1.0: Biological life with fixed hardware and software, such as bacteria.
  • Life 2.0: Beings like humans, whose behavior can be learned and adapted during their lifetime, though their biology remains fixed.
  • Life 3.0: A new class of intelligence that can redesign not only its behavior but also its underlying architecture and objectives — essentially, intelligence that builds itself.

Life 3.0


Figure 7. The three stages of life according to Max Tegmark.

While DGM currently focuses on evolving the “software” 3 , it exemplifies the early stages of Life 3.0. By iteratively rewriting its own code based on empirical feedback, DGM demonstrates how AI systems could move beyond human-designed architectures to autonomously explore new designs, self-improve, and potentially give rise to entirely new species of digital intelligence. If this trend continues, we may witness a Cambrian explosion in AI development, where eventually AI systems will surpass human-designed architectures and give rise to entirely new species of digital intelligence. While this future looks promising, achieving it requires addressing significant challenges, including:

  • Evaluation Framework: Need for more comprehensive and dynamic evaluation systems that better reflect real-world complexity and prevent “reward hacking” while ensuring beneficial AI evolution.
  • Resource Optimization: DGM’s evolution is computationally expensive 4 , thus improving efficiency and reducing costs is crucial for broader adoption.
  • Safety & Control: As AI self-improvement capabilities grow, maintaining alignment with human ethics and safety becomes more challenging.
  • Emergent Intelligence: Need to develop new approaches to understand and interpret AI systems that evolve beyond human-designed complexity, including new fields like “AI interpretability” and “AI psychology”.

In my view, DGM is more than a technical breakthrough, but rather a philosophical milestone. It invites us to rethink the boundaries of intelligence, autonomy, and life itself. As we advance toward Life 3.0, our role shifts from mere designers to guardians of a new era, where AI does not just follow instructions, but helps us discover what is possible.

Footnotes

[1] More precisely, the metacode that controls its behavior and ability.

[2] Those that might contain novel or unconventional ideas.

[3] Here, "software" refers to the code and strategies of AI agents.

[4] The paper mentioned that a complete SWE-bench experiment takes about two weeks and about $22,000 in API call costs.

References

  1. Learning to learn: Introduction and overview. Thrun, S. and Pratt, L., 1998. Learning to learn, pp. 3--17. Springer.
  2. Godel machines: self-referential universal problem solvers making provably optimal self-improvements. Schmidhuber, J., 2003. arXiv preprint cs/0309048.
  3. Darwin Godel Machine: Open-Ended Evolution of Self-Improving Agents. Zhang, J., Hu, S., Lu, C., Lange, R. and Clune, J., 2025. arXiv preprint arXiv:2505.22954.
  4. SWE-bench: Can Language Models Resolve Real-world Github Issues? Jimenez, C.E., Yang, J., Wettig, A., Yao, S., Pei, K., Press, O. and Narasimhan, K.R., 2024. International Conference on Learning Representations.
  5. AlphaEvolve: A coding agent for scientific and algorithmic discovery. DeepMind, G., 2025. Google DeepMind Technical Report.

By , No comments:
Tags , , ,

Using Grids in Interface Designs

Mike's Notes

The Ajabbi UI is going to be more like Craigslist rather than Squarespace. A bit clunky, predictable, straightforward to use and able to be reliably laid out by a robot in multiple languages and writing systems, including sign languages and AAC picture language. In Desktop, mobile, braille and kiosk formats.

That's why the early draft webpages at Ajabbi.com resemble Wikipedia.

I read this article to see if this could help with the layout rules that apply as constraints on the layout robot.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > NNGroup
  • Home > Handbook > Design System
  • Home > pipiWiki > Design System Engine

Last Updated

27/06/2025

Using Grids in Interface Designs

By: Kelly Gordon
NNGroup: 17/07/2022

Kelley Gordon is the Director of Product at Nielsen Norman Group. She plays a crucial role in driving the success of NN/g’s digital products, including the strategy, design, development, and management of it.

Summary:

Grids help designers create cohesive layouts, allowing end users to easily scan and use interfaces. A good grid adapts to various screen sizes and orientations, ensuring consistency across platforms.

If you’ve been to New York City and have walked the streets, it is easy to figure out how to get from one place to another because of the grid system that the city is built on. Just as the predictability of a city grid helps locals and tourists get around easily, so do webpage grids provide a structure that guides users and designers alike. Because of their consistent reference point, grids improve page readability and scannability and allow people to quickly get where they need to go.

Grid: A visual made up of columns, gutters, and margins that provide a structure for the layout of elements on a page.

There are three common grid types used in websites and interfaces: column grid, modular grid, and hierarchical grid.

Common Grid Structures in Websites and Interfaces

The column, modular, and hierarchical grid are commonly used in interfaces.

Column grid involves dividing a page into vertical columns. UI elements and content are then aligned to these columns.

Modular grid extends the column grid further by adding rows to it. This intersection of columns and rows make up modules to which elements and content are aligned. Modular grids are great for ecommerce and listing pages, as rows are repeatable to accommodate browsing.

Hierarchical grid: Content is organized by importance using columns, rows, and modules. The most important elements and pieces of content take up the biggest pieces of the grid.

In This Article:

  • Breaking Down the Grid
  • Examples of Grids in Use
  • Benefits of the Grid 
  • Choosing and Setting Up Your Grid
  • Conclusion

Breaking Down the Grid

Regardless of the type of grid you are using, the grid is made up of three elements: columns, gutters, and margins.

Columns: Columns take up most of the real estate in a grid. Elements and content are placed in columns. To adapt to any screen size, column widths are generally defined with percentages rather than fixed values and the number of columns will vary. For example, a grid on a mobile device might have 4 columns and a grid on a desktop might have 12 columns.

Gutters: The gutter is the space between columns that separates elements and content from different columns. Gutter widths are fixed values but can change based on different breakpoints. For example, wider gutters are appropriate for larger screens, whereas smaller gutters are appropriate for smaller screens like mobile.

Margins: This refers to the left and right outermost areas on the screen. Content does not live in the margins of a grid. This space can be fixed or expressed as a percentage of the screen width and can change at different breakpoints.

Annotated picture of a column grid

Three elements make up any grid: (1) columns, (2) gutters, and (3) margins.

Examples of Grids in Use

Example 1: Hierarchical Grid

Our first example is from The New York Times. This screen utilizes a hierarchical grid to create a newspaper-like reading experience. At desktop screen size, two main columns make up the hierarchical grid. The most important news story takes up the most space in the grid, the left column, followed by secondary and tertiary stories, which take up the smaller column and modules on the right.

The New York Times annotated with a hierarchical grid.

The New York Times uses a hierarchical grid to achieve its newspaper-like reading experience. (We highlighted the columns in yellow, the gutters in blue, and the margins in purple.)

Example 2: Column Grid

Our second example is from Ritual.com, a vitamin company. This design uses a column grid to create an attractive visual experience. At this screen size, four consistently sized columns make up the grid structure and elements are aligned to and within these columns. The gutters, the spaces in between the columns, are also consistently sized and help the user visually separate the different products. The margins are independently sized and are the same between the left and right sides.

Ritual screen annotated with a four-column grid


Ritual’s four-column grid makes scanning products easy. (We highlighted the columns in yellow, the gutters in blue, and the margins in purple.)

Example 3: Modular Grid

Our third example is from Behance, a design library. The site’s design uses a modular grid to create a pleasant browsing experience. At desktop size, rows are made up of 4 consistently sized modules. Horizontal gutters are slightly thicker than vertical gutters and the margins are consistently sized on the left and right of the design. Like in previous example, the gutters visually separate each element.

Behance screen annotated with a modular grid.


Behance’s design uses a modular grid, which allows users to easily browse. (We highlighted the columns in yellow, the gutters in blue, and the margins in purple.)

Example 4: Breaking the Grid

Our last example is Shrine from Google’s Material Studies. This design uses a column grid, as we can see based on the left navigation, which is 2 columns wide. Look closely and you will see that some product images settle to the margins, while others do not. Breaking the grid like this makes it challenging to focus or quickly scan product images and calls more attention to some products over others. It is okay to break the grid every so often, as long as you have a valid reason for it.

Shrine screen annotated with a column grid


Breaking the grid produces a chaotic browsing experience for users. (We highlighted the columns in yellow, the gutters in blue, and the margins in purple.)

Benefits of the Grid 

Using a grid benefits both end users and the designers alike:

  • Designers can quickly put together well-aligned interfaces.
  • Users can easily scan predictable grid-based interfaces.
  • A good grid is easy to adapt to various screen sizes and orientations. In fact, grid layouts are an essential component of responsive web design. Responsive design uses breakpoints to determine the screen size threshold at which the layout should change. For example, a desktop screen may have 12 grid columns, which may be stacked on mobile so that the resulting layout has only 4 columns.

Behance mobile and web screen


At the mobile size, Behance’s one-column grid (left) was reflowed into a four-column grid structure (right).

Even more importantly, the grid is not a throw-away concept. It is used by both designers and developers alike. Be sure to communicate with your developers the grid structure used when creating the design, so they can implement it accordingly.

Choosing and Setting Up Your Grid

How you use and set up a grid is fundamental to creating well thought out layouts and experiences for your user.

Choose the right grid for your needs. Take time to think through what type of grid ­— column, modular, or hierarchical — best suits your needs. A hierarchical grid may be the best fit if one item on your page will always be more important than the surrounding elements. For example, hierarchical grids are great for online news platforms. If the content you need to display is highly variable, consider using a basic column or modular grid, as these provide lots of flexibility when designing. For example, elements and content can span across multiple columns or modules or just one to fit design needs.

Spend time setting up your grid. Once you have figured out what type of grid will work well for your needs, start setting it up. Determine the number of columns and the margin and gutter sizes relative to your screen sizes. You will most likely want to prepare for mobile, tablet, and desktop screens. A 12-column grid at laptop or desktop size is generally flexible enough for most design needs. The number of columns will decrease as your device size decreases. Wireframing tools like Sketch and Figma have quick and easy ways to set up and edit your grid, even after you have started designing.

Setting up grid structure in Figma


Easily set the number of columns, the gutter size, and margin size in Figma.

Always place content within columns, not gutters. The gutters should remain empty as you place elements on the grid in order to clearly separate and align content and elements.

Content or elements should be placed within and across columns, not gutters.

Consider using an 8px grid system. For most common devices, the screen size in pixels is a multiple of 8. Keeping grid-component values at a multiple of 8 will generally make it easier to scale and implement a grid.

Conclusion

Grids not only provide designers a structure on which to base layouts, but they also improve readability and scannability for end users. Use a good grid system that easily adapts to various screen sizes.

Grids 101

Kelley Gordon · 4 min

By , No comments:
Tags ,
Subscribe to: Posts (Atom)