.png)
3 weeks ago
1
I’m asked over and over again: Are you using AI? How are you integrating it? Is AI working for you? How is AI impacting the employment landscape?
As Atlas has recently launched in New York, this seemed like the perfect time to share my experiences with how AI has shaped the direction of software development so far. This first article will cover practical ways to integrate AI and how AI helped us launch the brokerage of the future.
Use AI to get your ideas and concepts in front of others with a very simple app or design before you start coding. It can then be shown to other people on the team, family, and friends. You can get immediate feedback before you pour in any substantial effort, and then start your work from a better baseline where you have some initial validation of the concept.
For example, if you’re doing a voice chat feature, you don’t have to go through and get everything working end-to-end. Talking and responses can be simulated with simple button presses to easily demo how it would work before embarking on full development. This helps avoid spending weeks bootstrapping something, hearing “Wow, that is amazing,” but then “I wouldn’t use that” for whatever you’re trying to sell.
Using AI to save time validating concepts is a very important use case for AI in startups. I cannot emphasize enough the amount of time we have saved trying different ideas and concepts. I know a lot of engineers love this phase and would rather not reduce the effort here, but we’re talking about getting a business started as quickly as possible, not personal fulfillment.
Don’t spend too much time looking for the perfect tool. Sample the most popular ones and find what works for you. I prefer 16x prompt, but others on the team prefer Claude Code. Both get the job done. I prefer 16x because it isn’t as integrated, and it forces me to better understand the context I’m feeding the AI. I have to look at smaller snippets of code, which makes it easier to review. As far as choosing the AI model, Claude/Anthropic is the best out there. If you’re paying per token and not on a monthly plan, then using Claude Sonnet is more than sufficient.
Architecture is the important step to integrating AI successfully, and it’s as much feel as it is technical expertise. When bootstrapping, one of your first short term goals is to get to investment or profit quickly. Architecturally, you need to do the bare minimum to support what you think is required to get to the money (plus 25-50% more since it will take longer than you think) and allow flexibility for future integrations. Ideally, you don’t want to completely redesign everything the day after you get funding. Herein lies the art of startup architecture, balancing how much to design and build vs getting the product to market.
Spend time on designing items like:
Data access layer
Common way of handling authentication for the API endpoints
Common way of calling services from the various clients (web, iOS)
If you are using hooks or providers, a standard way to implement and access
The importance of this will be realized in seeing how AI can greatly reduce development time in those areas.
Make sure you have a rough idea of the data model. We spent way too much time “learning as we go,” which caused a lot of churn. Part of this was caused by plowing ahead trying to get this in front of customers ASAP and we had to refactor multiple times. Part of this was unavoidable as we learned important items that caused pivots as we progressed.
Once you have a working architecture, AI can be very useful in adding new features and APIs. This workflow worked very well for us:
Create a sample JSON with how the data will look. This may be an input request and how the data will look when stored and returned.
Ask AI to create a data model in the backend (pass in a previous example for reference).
For all the interactions with the database, ask AI to create the database access functions you need (pass in a previous example for reference).
For the actual REST APIs your client will call, give the AI a list of endpoints (pass in a previous example for reference).
For the client(s), ask to create the respective objects you need from the JSON (pass in a previous example for reference).
Then ask AI to create any services, hooks, etc. for the functions to match the API (pass in a previous example for reference).
As you probably noticed, I repeated myself many times. This is to emphasize the point that if you spend the time on basic architecture, you can use AI to do a lot of scaffolding to automate the generation of all that code. In the past this would have taken days or weeks and now it takes hours. While the developer has to create the first iteration all subsequent code can be inferred by the AI. Usually the AI creates correct code, but you especially have to look at the data models to ensure all the data types are correct, set any required or optional fields, and make sure all the functions do exactly what you want. If you have special functionality for these calls, you will have to add that in, but this will save hours generating boilerplate code and will greatly reduce cut-and-paste errors.
This is just one example of an entire workflow that can be AI assisted to save substantial time.
At this point, we needed a little polish on the UI. We’ve been fortunate enough to find someone to handle this. She helped refine the logo further, generated a color palette, and provided a marketing branding guideline. AI can assist with the UI/UX, but there still needs to be a human guiding the design and direction. If you do not have this expertise on the team, it will be a difficult step to put the final polish on things. If you cannot find UI/UX help (or do not want to pay out equity for that), consider waiting until you have a mostly finished project and then engage a designer. This is still a work in progress for Atlas.
We’ve spent a lot of time talking about resourcing internally. Here’s how I view things: the team is made up of a couple of senior engineers managing a team of “junior engineers” (AI) who can sometimes write brilliant code, but it’s buggy and untested at times, and frequently doesn’t understand the domain.
With AI, there is a reduced need for junior engineers. It is hard to justify their cost to investors, especially in a startup environment. We anticipate that AI will reduce the initial development need by 1/2 to 2/3 but we recognize that we will still need at least one UI/UX person.
The further we get into the project, the productivity gains we were seeing are decreasing. AI absolutely speeds things up, but nowhere near the 10x increase that we saw during prototyping. The gains are anywhere from 10% to 100% faster than without AI. As time goes on those gains are increasingly on the lower end. Even with these smaller gains, we can still get the job done with a smaller team.
There are times where AI cannot solve the problem. The issue may be due to the prompting or context provided; other times, it just can’t be solved. When the AI starts to “go in circles,” it is a good indication that the problem should be solved without AI.
Integration with external APIs sometimes can take more effort with AI. Occasionally, AI will generate good code; often the code will be a mix and match of incompatible or older API versions. In cases where the API changes frequently, the AI often can’t find a suitable API to use, so the AI creates code that doesn’t run at all. The best option is to learn the API you are integrating with, ensure you are using the “best version” for your use case, and implement it yourself.
At times, AI will generate code that will revert a previous change made if the AI feels the code is better the old way. You must verify the code being produced to ensure there are no unintended side effects.
Sometimes AI can produce code that “looks correct” but is wrong. For example, we had a bug during development where the time was off by one hour. The prompt to AI was: “The code is off by an hour and doesn’t account for daylight saving time. Can you fix it?” AI hardcoded the time to offset by one hour instead of fixing the real problem which was an incorrect time zone. Doing a test after the new code was produced showed the “problem was fixed,” but after looking at the code, we realized that when daylight savings time ends, the time would be off again. If the code was not manually reviewed, we would not have caught this error until the clocks changed.
Which brings me to the final point: all code needs to be reviewed. The quality of code AI produces can be anywhere from code that will not work to Principal Engineer level code. Review your code.
I hope you’ve found this useful and have gotten some practical advice. If you have, please give us a follow, and if you have other tips, please share in the comments so others can learn from them.
David Madurzak is the Founding Engineer of Atlas. He has been building software for many years—everything from early-stage startups to Fortune 500 companies. David has built, designed, and architected systems that have supported millions of users. He has worked on 0-to-1 projects multiple times, learning a lot of hard lessons along the way. David is now sharing what’s working (and what’s not) as Atlas is built out. Follow along if you want tips and guidelines on how to build successful startup products.
