Vibeposting in the Community Forum

Hey everyone

This is my first post here, so I wanted to start with something I’ve been thinking about a lot lately , vibecoding.

It feels like we’re entering a phase where coding is less about writing everything line by line, and more about describing intent, experimenting fast, and letting AI help shape the implementation.

But I’m still trying to understand where this is really heading.

  • Is vibecoding actually making developers more productive?
  • Or are we just shifting complexity from code → prompt design?
  • And what happens to core engineering skills in the long run?

From what I’ve seen, it’s exciting but also a bit confusing. Sometimes it feels like you can build 10x faster… but then debugging and understanding what’s happening under the hood becomes its own challenge.

Curious how others here see it:
Are you using vibecoding in your workflow already? And do you think it’s the future of building software or just a phase we’re in?

Would love to hear your thoughts

I recently built a small internal AI tool that could answer questions from company documents. Getting the model to work was surprisingly easy. Keeping the data organized, versioned, and accessible as the app evolved was much harder.

That’s what led me to experiment with Vibecode DB. What I liked wasn’t that it generated anything magical—it helped me spend less time worrying about database setup and more time testing actual product ideas.

My biggest takeaway: AI prototypes fail less because of model quality and more because the surrounding infrastructure isn’t ready to grow beyond a demo.

Curious what others have found. When building AI products, what’s been the biggest bottleneck for you: prompts, data, infrastructure, or deployment?

I would say the data layer is the most difficult part in any software building, be it with AI or engineers. In my opinion the complexity comes from three things:

  1. The infrastructure
  2. The design
  3. The architect’s understanding of the business as a whole, its goals, priorities, and how the whole system should work to solve the problem (yet you need to be capable to spot the problem, preconditions, formulate the problem clearly and identify the alternative approaches to solving it)

That third one is probably the most difficult on its own. And basically this is the reason why the other two often fail. And once you have your data layer wrong, everything else is wrong.

The mind behind the decisions…

The interesting part isn’t that Codex can write code.

It’s that it can:

  • Understand an existing codebase
  • Make multi-file changes
  • Run commands
  • Work directly from the terminal

That said, I’m curious how people are using it in real projects.

Are you treating Codex CLI as:

  1. A coding assistant?
  2. A code reviewer?
  3. A debugging partner?
  4. An autonomous agent for repetitive tasks?

My biggest takeaway so far: the bottleneck is no longer writing code, it’s deciding what should be automated and what still needs human judgment.

I treat it as a whole developer team.

Human judgement is required mainly to set goals, verify results and polish UI/UX.

As AI products move from prototypes to production, I keep noticing the same debate:

Cloud-native or cloud-agnostic?

Most discussions frame it as a technical decision, but it often feels more like a business-stage decision.

A startup trying to reach product-market fit has very different priorities than an enterprise managing compliance, cost optimization, and vendor risk.

Have you seen teams regret choosing one approach too early?

Would love to hear real-world experiences, especially from teams scaling AI products.

Curious what others have found. When building AI products, what’s been the biggest bottleneck for you: prompts, data, infrastructure, or deployment?

I don’t know if this is the right question. When you say “When building AI products”, I’m assuming a new application from scratch. So @sergeliatko statement as a first step is correct:

The architect’s understanding of the business as a whole, its goals, priorities, and how the whole system should work to solve the problem.

The next step, and arguably the most challenging, is to design the database or databases and the selection of the DBMS while keeping in mind potential user growth:

  • If the number of users will be small, then a simple DBMS, with normal CRUD support, should be sufficient.

  • If a large user base is projected, then a Enterprise level DBMS will be required with the following featues: Concurrency Control; Scheduled Database & Log Backups; Disaster Recovery Plans. I don’t know if I would trust AI agents on any of this - one rogue agent could kill everything.

Next are the SQL query designs which should be made in conjuction with your Presentation Layer. Note that while AI agents could handle this, there may be uneccessary token burn.

Next is your Presentation Layer, UI/UX.

Throughout all the above, unit testing is critical. So many devs skip this process resulting in failed projects.

For agent specifics a good approach showed up:

DB introspection tooling (state machine+some reconciliation logic between architecture intent, tests, and what is actually running now, diff able and deterministic).

Just landed that for me, awesome reality check for agents.

I bet next thing is automated “architecture drift” tooling to keep AI slop away.

It appears that you changed the title and your initial post after I made my post to include a discussion of Vibecoding.

Please disregard my post as it is not appropriate for Vibecoders.

Thank you.

Enterprise AI discussions seem to be moving away from chatbots and toward agents that can execute workflows across systems.

The biggest challenge doesn’t appear to be model capability anymore. It’s orchestration, permissions, monitoring, and reliability.

Companies like OpenAI, Anthropic, Thoughtworks, EPAM, and GeekyAnts are all contributing ideas around production-ready agent architectures.

Are managed agents becoming the default enterprise AI pattern?

I think many companies are moving in that direction. Creating a chatbot is much easier today than building an AI agent that can actually perform tasks across different systems. The bigger challenge is making sure it works reliably, has the right permissions, and can be monitored properly. Managed agent platforms can make this easier, especially for businesses that don’t want to build everything from scratch.

Yes

The trend I see with both OpenAI Codex and Anthropic Claude is toward agents that can execute larger workflows, rather than simply answer isolated prompts.

For the past several months, I have been checking the daily commits for these projects almost every day. More recently, I have also been getting a daily ChatGPT summary that highlights recent trends, backed by commits, changelogs, or other concrete changes.

Based on that, managed agents are increasingly becoming the expected pattern, not just exclusive to entrprise, especially for workflows that need orchestration, tool use, review, and repeatability.

I agree in full here. Having the use of HL7v2, or FHIR, SNOMEC CT, IHE profiles and such is really important. What is even more so is to have ChatGPT or any given AI at an MDR or FDA Certified level for medical. Without thorough due process of this it becomes tricky, even if the models are fully capable.

Nevertheless many clinical information systems do integrate AI as a companion where a health professional still decides the next steps. As far as I know Epic, Orbis already have this in their products.

Use Case On-Premise

I‘ve been researching on my own how to implement a FHIR Orchestrator based on Patient Data ingested by an agent so that the corresponding bundles of a first patient-doctor encounter in a GP setting are produced. There are many semantic challenges where the diagnostics just stray.

Example: Cervical Cancer usually defaults to the female body context rather than other types of cervices found in the body.

Use Case Ambulatory and Out-Patient

There is an increasing need to have care outside an inpatient setting where continuous care is needed. This can be from a one time visit to a clinic to pre-diagnose workflows. Proper on demand adaptive care shines when using Generative AI to track vitals and parameters needed in a patient’s pathway. Here once again interoperability is paramount in a cross-domain way (XSD Schemes) and most likely SMART on FHIR play a big role.

Use Case Frontier Bound

Adjacent to what is the general trend in healthcare, there are underrepresented disciplines and domains that would benefit a lot from AI. These are mainly psychiatry, psychology, assisted living, neurodivergence, to name a few. Some of these domains have formal medical procedure while others are, for the lack of a better term, in the grey area. This grey area is a place where standards are not thoroughly defined or a workforce has shown resistance to implement such standards.

I hope this gives you an idea, should you choose to set path in healthcare. :grin:

Final Note: vibe coding will have a huge hurdle to overcome and be accepted in medical.

@PaulBellow thanks for moving the post here, it‘s a more suitable and gave me the ability to pose further use cases in healthcare.

By chance. have you run into any discussions concerning encryption?

To date, I have yet to see any discussions of encryption with respect to Codex - forget about ChatGPT. And by encryption, I am not talking about Transport Layer Encryption (e.g. Transport Layer Security (TLS)).

I’m talking about Data Layer Encryption where data is encrypted at rest and requires a comprehensive Key Management System.

Maybe agents could eventually handle this - they better, or else!

This is interesting, I’m curious to hear more about this. There are some scenarios in medical and banking, where exactly this is needed. There are other scenarios for example where data, due to it’s sensitivity are regulated in a way that cannot be loaded into volatile memory and yet needs to be encrypted. Including at TLS they have specified factors.

It can be argued that all public and many private enterprises need this.

Here is a simple typical flow: ClientA sends encrypted data to ClientB (via TLS) to a cloud database. Only ClientA and ClientB know the encryption key.

The cloud provider has no knowledge of the key and stores the encrypted data from ClientA at rest.

ClientB accesses the encrypted data (via TLS) from the cloud provider. ClientB then decrypts the data into local memory using the shared key.

All of this is accomplished via a key management system, most of which are provided by trusted third parties.

A more complex example is the AWS FedRAMP:

I’m interested as general knowledge.

At some point what would be nice is to have support of codex with SMART on FHIR which would be tailored to more to my use cases.

But TLS in itself is quite interesting.

As for added extras, relevant for use cases in this thread that could be done in healthcare could check what is being done in this Gallery from the previous link.

Side note: Hope FedRAMP gets fixed soon for OpenAI, it’s been looming with service degradation for a while now.

I have not been looking specifically for discussions about data-layer encryption. The updates I see are usually generated by ChatGPT from either ChatGPT Pulse or from searches for recently raised issues.

That said, there does seem to be a broader focus lately on security-related topics, such as sandboxing, permissions granted to agents, agents running locally, and agents connecting through MCP or similar mechanisms.

My personal concern, which I have not tested directly, is the pace and fluidity of the changes. Rapid changes can sometimes expose security gaps, or leave gaps that have not yet been closed.

I am also somewhat concerned by the lack of visible testing before code is committed. However, I do not have access to all of the code or internal processes, so those tests may exist even if I cannot see them.

Yes, I do think security and encryption should be on the short list of concerns whenever sensitive data is leaving, entering, or being processed outside a protected and isolated environment.


For those wondering how terms such as Transport Layer and Data Layer relate to one another, a useful reference point is the Open Systems Interconnection (OSI) model. The OSI model separates network communication into layers, which can make it easier to discuss where a particular security, encryption, or data-handling concern belongs.

Note: There are hundreds of OSI model reference documents available online. Personally, I prefer sources that are vendor-neutral and not tied to a specific proprietary product, platform, or implementation. Those tend to make it easier to understand the model itself rather than a particular company’s interpretation of it.

Received an update from ChatGPT that noted this Codex PR